Masking in Validations
Hi, I have used masking in my Validations where in I restrict the user to enter things. I would like to allow the user to use ENTER in a TEXT AREA. How should this be achieved.? Thanks Regards, Sahil Gupta Extn : 233 Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ** NetEdge Computing Global Solutions Private Limited. A-14, Sector-7, NOIDA U.P. 201-301 Tel # 91-120-2423281, 2423282 Fax # 91-120-2423279 URL http//www.netedgecomputing.com ** This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Invalidating a session using JAVASCRIPT
Hi, Can anyone tell me how to logout a user (invalidate his Session) when a user directly closes his browser window. Thanks. Regards, Sahil Gupta Extn : 233 Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ** NetEdge Computing Global Solutions Private Limited. A-14, Sector-7, NOIDA U.P. 201-301 Tel # 91-120-2423281, 2423282 Fax # 91-120-2423279 URL http//www.netedgecomputing.com ** This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: struts submit tag
raghava reddy ha scritto: Hi all I am using a html:form in that i want to keep my own login image if i use html:submit it is keeping ordinary submit button please help me RTFM: http://struts.apache.org/struts-taglib/tagreference-struts-html.html#html:image Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invalidating a session using JAVASCRIPT
Hi Sahil, I believe this can be done by implementing the HttpSessionBindingListenerInterface.The HttpSessionBindingListener interface is implemented by the classes whose objects need to receive notifications whenever they are added to or removed from a session. We do not have to inform the container about such objects explicitly via the deployment descriptor. Whenever an object is added to or removed from any session, the container introspects the interfaces implemented by that object. If the object implements the HttpSessionBindingListener interface, the container calls the corresponding notification methods Rajasekhar Cherukuri Tata Consultancy Services Limited Air-India Building 11th Floor, Nariman Point , Mumbai - 400 021,Maharashtra India Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com Sahil Gupta [EMAIL PROTECTED] 03/21/2006 04:08 PM Please respond to Struts Users Mailing List user@struts.apache.org To user@struts.apache.org cc Subject Invalidating a session using JAVASCRIPT Hi, Can anyone tell me how to logout a user (invalidate his Session) when a user directly closes his browser window. Thanks. Regards, Sahil Gupta Extn : 233 Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ** NetEdge Computing Global Solutions Private Limited. A-14, Sector-7, NOIDA U.P. 201-301 Tel # 91-120-2423281, 2423282 Fax # 91-120-2423279 URL http//www.netedgecomputing.com ** This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ForwardSourceID:NT0001060A Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
RE: Invalidating a session using JAVASCRIPT
I think he doesn't want to catch those events. He wants to invalidate session on clicking window's close button. /Ashwani -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 4:08 PM To: Struts Users Mailing List Subject: Re: Invalidating a session using JAVASCRIPT Hi Sahil, I believe this can be done by implementing the HttpSessionBindingListenerInterface.The HttpSessionBindingListener interface is implemented by the classes whose objects need to receive notifications whenever they are added to or removed from a session. We do not have to inform the container about such objects explicitly via the deployment descriptor. Whenever an object is added to or removed from any session, the container introspects the interfaces implemented by that object. If the object implements the HttpSessionBindingListener interface, the container calls the corresponding notification methods Rajasekhar Cherukuri Tata Consultancy Services Limited Air-India Building 11th Floor, Nariman Point , Mumbai - 400 021,Maharashtra India Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com Sahil Gupta [EMAIL PROTECTED] 03/21/2006 04:08 PM Please respond to Struts Users Mailing List user@struts.apache.org To user@struts.apache.org cc Subject Invalidating a session using JAVASCRIPT Hi, Can anyone tell me how to logout a user (invalidate his Session) when a user directly closes his browser window. Thanks. Regards, Sahil Gupta Extn : 233 Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ** NetEdge Computing Global Solutions Private Limited. A-14, Sector-7, NOIDA U.P. 201-301 Tel # 91-120-2423281, 2423282 Fax # 91-120-2423279 URL http//www.netedgecomputing.com ** This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ForwardSourceID:NT0001060A Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with character encoding.
Hi all, I am generating a MS Word document through a JSP, by setting the JSP's content type as application/msword;. The .doc that is generated contains accentuated French characters (special French characters). I use Websphere (WSAD) to develop the code, but use Tomcat server for deployment final testing. In WSAD, the .doc file that is generated properly displays the special characters. But, in Tomcat, these characters are broken (distorted). The code snippet (in JSP) is as follows: %@ page language=java contentType=application/msword; charset=UTF-8 pageEncoding=UTF-8 % % String fileName = abc.doc; response.setContentType(application/msword); response.setLocale(java.util.Locale.FRENCH); response.setHeader(Content-Disposition,attachment;filename=+ fileName); % Can anyone give me some pointer, regarding the problem might be? Am I missing out something? Thanks for your time. With best regards, Anjishnu. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
RE: Invalidating a session using JAVASCRIPT
Use
body onUnload=callAMethod()
...
/body
script
function callAMethod(){
submit to server(may be a servlet);
}
/script
I have not tested this by summiting to a servlet.But, I am sure
onUnload() works when you click on browser 'X;
Chandra
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 21, 2006 4:08 PM
To: Struts Users Mailing List
Subject: Re: Invalidating a session using JAVASCRIPT
Hi Sahil,
I believe this can be done by implementing the
HttpSessionBindingListenerInterface.The HttpSessionBindingListener
interface is implemented by the classes whose objects need to receive
notifications whenever they are added to or removed from a session. We
do not have to inform the container about such objects explicitly via
the deployment descriptor. Whenever an object is added to or removed
from any session, the container introspects the interfaces implemented
by that object. If the object implements the HttpSessionBindingListener
interface, the container calls the corresponding notification methods
Rajasekhar Cherukuri
Tata Consultancy Services Limited
Air-India Building 11th Floor,
Nariman Point ,
Mumbai - 400 021,Maharashtra
India
Mailto: [EMAIL PROTECTED]
Website: http://www.tcs.com
Sahil Gupta [EMAIL PROTECTED]
03/21/2006 04:08 PM
Please respond to
Struts Users Mailing List user@struts.apache.org
To
user@struts.apache.org
cc
Subject
Invalidating a session using JAVASCRIPT
Hi,
Can anyone tell me how to logout a user (invalidate his Session) when a
user directly closes his browser window.
Thanks.
Regards,
Sahil Gupta
Extn : 233
Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
**
NetEdge Computing Global Solutions Private Limited.
A-14, Sector-7, NOIDA U.P. 201-301
Tel # 91-120-2423281, 2423282
Fax # 91-120-2423279
URL http//www.netedgecomputing.com
**
This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
ForwardSourceID:NT0001060A
Notice: The information contained in this e-mail message and/or
attachments to it may contain confidential or privileged information. If
you are not the intended recipient, any dissemination, use, review,
distribution, printing or copying of the information contained in this
e-mail message and/or attachments to it are strictly prohibited. If you
have received this communication in error, please notify us by reply
e-mail or telephone and immediately and permanently delete the message
and any attachments. Thank you
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Invalidating a session using JAVASCRIPT
Ya that's right. I want to invalidate the session when the window closes without performing a logout. Regards, Sahil Gupta Extn : 233 Email : [EMAIL PROTECTED] ** NetEdge Computing Global Solutions Private Limited. A-14, Sector-7, NOIDA U.P. 201-301 Tel # 91-120-2423281, 2423282 Fax # 91-120-2423279 URL http//www.netedgecomputing.com ** -Original Message- From: Kalra, Ashwani [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 4:21 PM To: Struts Users Mailing List Subject: RE: Invalidating a session using JAVASCRIPT I think he doesn't want to catch those events. He wants to invalidate session on clicking window's close button. /Ashwani -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 4:08 PM To: Struts Users Mailing List Subject: Re: Invalidating a session using JAVASCRIPT Hi Sahil, I believe this can be done by implementing the HttpSessionBindingListenerInterface.The HttpSessionBindingListener interface is implemented by the classes whose objects need to receive notifications whenever they are added to or removed from a session. We do not have to inform the container about such objects explicitly via the deployment descriptor. Whenever an object is added to or removed from any session, the container introspects the interfaces implemented by that object. If the object implements the HttpSessionBindingListener interface, the container calls the corresponding notification methods Rajasekhar Cherukuri Tata Consultancy Services Limited Air-India Building 11th Floor, Nariman Point , Mumbai - 400 021,Maharashtra India Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com Sahil Gupta [EMAIL PROTECTED] 03/21/2006 04:08 PM Please respond to Struts Users Mailing List user@struts.apache.org To user@struts.apache.org cc Subject Invalidating a session using JAVASCRIPT Hi, Can anyone tell me how to logout a user (invalidate his Session) when a user directly closes his browser window. Thanks. Regards, Sahil Gupta Extn : 233 Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ** NetEdge Computing Global Solutions Private Limited. A-14, Sector-7, NOIDA U.P. 201-301 Tel # 91-120-2423281, 2423282 Fax # 91-120-2423279 URL http//www.netedgecomputing.com ** This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ForwardSourceID:NT0001060A Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - 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: Problem with character encoding.
Anjishnu Bandyopadhyay ha scritto: Hi all, I am generating a MS Word document through a JSP, by setting the JSP's content type as application/msword;. Are you using a particular library to generate the file? Anyway generating an MS Word file through JSP seems odd to me... The .doc that is generated contains accentuated French characters (special French characters). ... In WSAD, the .doc file that is generated properly displays the special characters. But, in Tomcat, these characters are broken (distorted). Maybe I am missing something. Does WSAD have something native that handles MS Word files? Because Tomcat doesn't! Anyway, the character set (UTF-8) has nothing to do with the final generated file (for the browser it should be a binary file, that must be handled by a plugin or an external application). Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Frank W. Zammetti wrote: Jonathan Revusky wrote: Well, have you considered the positional issues I raised in the earlier post? The order in which people vote is quite important. Offhand, here is an idea: You know, I meant to address that and I completely forgot :) I think you do raise a valid issue. I'm not really sure how to solve it... simple anonymous vote seems the best answer, but how do you pull that off? If you have a webapp specially for people to vote, someone could always accuse you of cooking the code :) I guess you and I think quite differently about certain things. In another part of this discussion, you mentioned malice as a reason not to give people commit access on an on-demand basis. However, this is something that hardly occurs to me as being much of a reason. In the above, you mention the idea that your secret voting mechanism could be cooked or people could suspect it is. This also never really occurred to me. I guess I just have a certain basic trust in the ethics of other open source people, and it does not occur to me that someone would cook the voting or that anybody would think that I would cook the voting. But look, if somebody distrusts your ethics to that extent, why would they be in your community? That is I think one of the reasons most projects go with a public vote on a list, and I tend to agree. Well, you know, it could also be that a public vote is preferred because project leaders are (at least vaguely) aware that if the vote is public people are less likely to disagree with them. (Of course, that is not exactly a legitimate reason.) Maybe you should have a vote that is non-binding among the simple users. Effectively if most users are against something, then the idea is not immediately rejected, but it is indicative of a need for more debate. If most users are in favor, then you could move on to the committers voting and so on. The problem is that once the people higher on your pecking order, your PMC, vote +1, this will bias the votes of the lower status people. (Also, the PMC are the people who are -- hopefully -- more involved and are likely to put in their votes with less delay.) The results of the voting is bound to be highly dependent on the order in which voting takes place, don't you think? Yes, I do agree it is a concern. I'm not sure I would say it is *highly* dependent on order, but I *do* think it comes into play. Well, if it comes into play at all, it should be considered. Well, I just proposed a few changes to the bylaws on the JWP mailing list, and I wish I hadn't forgotten about this point because I would have tried to address it too. I have to think about it a bit and try and find a decent solution, I'm not sure what it might be at the moment. Your intent is good, but I am skeptical that all this formalized voting is really the way open source projects should work. I'm not saying I have all the alternatives figured either. You know, it's funny, but a few years ago I was quite the anti-open source guy :) I've definitely changed my thinking on some things over the years. Well, maybe (just maybe, I'm not really *so* presumptuous) the next step of evolution of your thinking is to move more towards implicitly trusting people. I mean: trust people to be acting in good faith until proven otherwise. Trust people to be at least moderately competent until proven otherwise. In general, in this kind of collaborative internet model, don't you have to make a leap of faith and implicitly trust (until proven otherwise, of course) people you've never met? You see, what is the alternative? If you don't trust people by default, then how is trust established? I mean, this seems to be related to the catch 22 problem that you become a committer by contributing a lot, but it's practically impossible to contribute without being a committer in the first place, Craig never responded to this basic question. (Somehow, I suspect he won't.) AFAICS, what this kind of thing has led to is complete stagnation, where Struts has become so uncompetitive that everybody just had to accept that Webwork was better. What I also see, just as a lurker here, is that there is a complete lack of willingness to really deal with the implications of this. I mean, when you've had to accept that Struts stagnated and Webwork progressed, how can you not be somewhat humble when discussing these kinds of project management issues? Actually, you know, in the earlier message, where I used the terms immature and unwise in my response to Craig, an earlier draft contained much harsher adjectives. Of course, when somebody says stuff like: Deal with it or go away that person is hardly expressing a willingness to have an open-minded exchange of ideas about something. Frankly, I don't think that kind of tone or attitude should be considered acceptable. But the real problem here, that just about
Re: has struts reached the saturation
As much as I detest the thought of getting into it again with you after all these years... Jonathan Revusky wrote: You see, what is the alternative? If you don't trust people by default, then how is trust established? Trust is earned over time. Two simplistic examples: I mountain climb and train in several martial arts. The first time I go climbing with somebody I do not automatically assume they have the prerequisite skills, attention to detail, etc. that I have and that are necessary to keep both of us alive. I double-check their knots, their belay stations, everything they do. I become nervous if they do not do the same to me. The first time I train a joint-locking art with someone I do not assume they have the sensitivity necessary to know when to stop twisting, pressing, sealing, etc. so I will tap early and often. I _do_ have the sensitivity necessary and my partners will often comment that I began releasing pressure just as they started the tap-out thought process... but I do not expect them to trust me to stop just before things get really painful. Plus if they do not tap I lose valuable feedback about my own techniques. The application to commit access would be similar. I would check their code. I would run regression tests. Once I became confident that their code quality is acceptable and they meant the project no harm then I would grant commit access. Is this optimal? Eh, I don't know, I suspect not as it would take a lot of my time, but it certainly shows one way trust can be established in a project context. I mean, this seems to be related to the catch 22 problem that you become a committer by contributing a lot, but it's practically impossible to contribute without being a committer in the first place, Craig never responded to this basic question. (Somehow, I suspect he won't.) This is a perfectly valid point... similar to every other situation in the real world: we won't hire you without experience. How do I get experience without being hired? I won't climb with you until you're more experienced. How do I get experience without climbing? It's a real problem. I _firmly_ believe that granting access to anybody that asks for it is a Very Bad Idea. One glance through the posts on this list is _more_ than enough to show me that if some of the posters asked for commit access they should _not_ get it. Yes, it's (relatively) easy to back changes out, but even that (relatively) easy process takes time that I'd rather spend doing other things. Actually, you know, in the earlier message, where I used the terms immature and unwise in my response to Craig, an earlier draft contained much harsher adjectives. Of course, when somebody says stuff like: Deal with it or go away that person is hardly expressing a willingness to have an open-minded exchange of ideas about something. Frankly, I don't think that kind of tone or attitude should be considered acceptable. Then don't accept it and go away? I just don't think the Apache project is going to change how things work (at least not drastically, at least not now). They don't have to care what we think. I really don't see what the problem with that is... Yeah, it might be wonderful if they did everything I wanted them to, let me have commit access to the particular projects I'm interested in, etc. But... they don't and won't, and I move on. But the real problem here, that just about everybody seems to be skirting around is that, given the utter failure of the Struts community to compete with Webwork technically, there surely is a need for an open-minded exchange of ideas about these project management issues. And the people who lost the technical competition (the Struts people) should, by the basic logic and structure of competitition, adopt a fairly humble attitude about these topics. Should implies a level of obligation that I am uncomfortable with. It's one thing to _want_ somebody to take a different position, it's quite another to imply that they are under some _obligation_ to do so. Quite frankly, if I was in the shoes of an Apache committer I'm not sure I'd change anything either, although I would have to give this meta-discussion more thought to be sure. I actually am not somebody with strong opinions at the moment about web app development. I don't know so much about Spring and other frameworks and so on. However, just from what I observe lurking in this community, I would have one recommendation for anybody who asked my opinion on these matters. And that is: Whatever else you decide on, do not use Struts (I mean, don't use Struts Classic, don't use Struts Action, don't use Struts Shale) because the community is dysfunctional... major league FUBAR... I agree that the community may be _one_ factor in deciding a technology, but I hardly feel it should be the _only_ factor. I _do_ believe that this thread, in some ways, is doing a disservice to the Struts umbrella. It's been disheartening in many ways,
Re: Problem with character encoding.
Are you using WSAD on Windows and Tomcat on Unix/Linux? - Original Message - From: Anjishnu Bandyopadhyay [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Tuesday, March 21, 2006 5:51 AM Subject: Problem with character encoding. Hi all, I am generating a MS Word document through a JSP, by setting the JSP's content type as application/msword;. The .doc that is generated contains accentuated French characters (special French characters). I use Websphere (WSAD) to develop the code, but use Tomcat server for deployment final testing. In WSAD, the .doc file that is generated properly displays the special characters. But, in Tomcat, these characters are broken (distorted). The code snippet (in JSP) is as follows: %@ page language=java contentType=application/msword; charset=UTF-8 pageEncoding=UTF-8 % % String fileName = abc.doc; response.setContentType(application/msword); response.setLocale(java.util.Locale.FRENCH); response.setHeader(Content-Disposition,attachment;filename=+ fileName); % Can anyone give me some pointer, regarding the problem might be? Am I missing out something? Thanks for your time. With best regards, Anjishnu. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with character encoding.
Anjishnu Bandyopadhyay wrote: I am generating a MS Word document through a JSP, by setting the JSP's content type as application/msword;. I really don't understand why you persist in thinking that _calling_ something a Word document _makes_ it a Word document. As I have stated several times a Word document is a _binary_file_format_. What are you using to generate the Word document? If you're just outputting an HTML template (e.g. a standard JSP template) you are NOT generating a Word document. If you are using a particular library to properly generate a Word document you'll probably want to ask on a list for that library. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Jonathan Revusky wrote: I guess you and I think quite differently about certain things. In another part of this discussion, you mentioned malice as a reason not to give people commit access on an on-demand basis. However, this is something that hardly occurs to me as being much of a reason. In the above, you mention the idea that your secret voting mechanism could be cooked or people could suspect it is. This also never really occurred to me. I guess I just have a certain basic trust in the ethics of other open source people, and it does not occur to me that someone would cook the voting or that anybody would think that I would cook the voting. No question I tend to take a pessimistic view of things until I have reason to believe otherwise. I dare say all you have to do is look around the world and you will see more evidence to support that perspective than the more positive perspective. Sad, but I think true. But you say ...certain basic trust in the ethics of other open source people.. do you mean that you would allow anonymous, full commit privileges to anyone and everyone? In other words, a situation where anyone who wants to, whether they have ever seen the project before or not, can commit to the repository. This I absolutely think is a bad idea. A very bad one at that. But look, if somebody distrusts your ethics to that extent, why would they be in your community? I guess it could be more me expecting people to be expecting the worst of me :) Well, you know, it could also be that a public vote is preferred because project leaders are (at least vaguely) aware that if the vote is public people are less likely to disagree with them. (Of course, that is not exactly a legitimate reason.) That could be part of it, sure. But now, which one of us has the basic distrust issue here?? ;) LOL Well, if it comes into play at all, it should be considered. I would generally agree. Well, maybe (just maybe, I'm not really *so* presumptuous) the next step of evolution of your thinking is to move more towards implicitly trusting people. I mean: trust people to be acting in good faith until proven otherwise. Trust people to be at least moderately competent until proven otherwise. With the potential of major effort to clean up a corrupt source repository, I don't think you can do that. Just my opinion. In general, in this kind of collaborative internet model, don't you have to make a leap of faith and implicitly trust (until proven otherwise, of course) people you've never met? To some degree, yes. But what that degree is, well, that's where we don't completely agree :) I think there has to be *some* vetting that takes place, no matter how minor. Look at it this way... let's say you have 20 people actively working on a project, doing fantastic work. All of a sudden, you let the 21st person in, and they proceed to commit some less than stellar work, or maybe even break code because they don't yet have a good understanding of the project. Is that fair to the 20 others? Even if it can all be undone, is it fair for any of them to have to take the time to do so? I could quote Spock here, but I probably don't need to :) You see, what is the alternative? If you don't trust people by default, then how is trust established? I mean, this seems to be related to the catch 22 problem that you become a committer by contributing a lot, but it's practically impossible to contribute without being a committer in the first place, Craig never responded to this basic question. (Somehow, I suspect he won't.) But this is where the attitude of the committers (of any project, not talking Struts specifically here) comes into play. They have to be willing to accept contributions that don't come from themselves. If that is the case, a person can build up that trust and build up that reputation that leads to an invitation to join. One could even envision a situation where a person submits 10 things, none of them is accepted, and the person is still invited to join. That obviously would require the existing committers have a very open-mindedness about them, but it could happen. This serves your point of view and mine: there is a vetting process that I like, and there is a basic trust by default for you, maybe not quite to the degree you like, but I think its a reasonable compromise position. But the real problem here, that just about everybody seems to be skirting around is that, given the utter failure of the Struts community to compete with Webwork technically, there surely is a need for an open-minded exchange of ideas about these project management issues. And the people who lost the technical competition (the Struts people) should, by the basic logic and structure of competitition, adopt a fairly humble attitude about these topics. Can you point out where Struts has utterly failed to compete with Webwork technically? I've looked
opening a pdf file from action class
In my download action class I set the content type and write byte array to the response which makes the browser open a dialog box save or open . Is there a way to open the file without the option save or open i.e. when user clicks on file link I want to open the file in the browser rather than a dialog box asking user to choose an option to save or open. How I can I achieve this? Thanks Regards - Yahoo! Mail Use Photomail to share photos without annoying attachments.
Re: opening a pdf file from action class
See if your question is addressed in this Wiki entry: http://wiki.apache.org/struts/ServingPdfDocuments Frank temp temp wrote: In my download action class I set the content type and write byte array to the response which makes the browser open a dialog box “save or open . Is there a way to open the file without the option save or open i.e. when user clicks on file link I want to open the file in the browser rather than a dialog box asking user to choose an option to save or open. How I can I achieve this? Thanks Regards - Yahoo! Mail Use Photomail to share photos without annoying attachments. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Synchronization of dispatch Action
Is it a good idea to synchronize DispathAction to make sure all requests
to DB and results which come back don't overstep each other ?
Pls help.
Following is some detail of what am I doing in my application.
I have few operation I want to synchronize.
In my app following steps I am taking
1. calling dispatch Action getInstrumentsFromQ as under, Should
this be synchronized ?
public ActionForward getInstrumentsFromQ(ActionMapping
mapping, ActionForm form, HttpServletRequest request, HttpServletResponse
response) throws Exception {
..
..
}
2. In Dao service I have couple of lists which are stored as Class
variable, where I store one I received from DB.
public class InstrumentDiceQdao extends BaseDao implements
InstrumentDao{
private List instruments =(List )
Collections.synchronizedList(new ArrayList());
private List instrumentDbItems = (List)
Collections.synchronizedList(new ArrayList());
public synchronized List
getAllInstrumentsFromQ(Long sectorId) throws DiceWebException {
...
...
}
}
3. I am putting service object which has results of all DB query
in Session, so I can access from various places in web.
InstrumentService instService = new
InstrumentDaoService(ds) ;
try {
synchronized(instService)
{
List instruments =
instService.getAllinstrumentsFromQ(sectorId);
session.setAttribute(InstrumentService,instService);
}
}
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries
and affiliates.
Re: Synchronization of dispatch Action
To answer your question, in general, its a very bad idea to
synchronize action methods as that will bring your webapp to a
screeching halt because Struts only creates a single instance of a
given action class. What you will be doing is essentially handling a
single request at a time, very bad.
Now, the reason why you want to synchronize access is based on a bad
design idea. You DO NOT want to have an instance to a database
connection shared between different requests because of the
concurrency issues you refer to. You don't even want to share a
connection within a session for a couple of reasons: you don't want a
connection open across different requests, and even if holding
connections open for a long time isn't bad enough, you can have
multiple client web pages that are part of the same session hitting
the same connection at the same time, which will certainly break
something, and probaly not until your web app is in production :-)
You need to do some research on how to use a connection pool, and then
have your DAOs either get a connection from the connection pool or
take a connection as an argument which will be supplied by the action.
I prefer the latter, that way you can chain operations on the database
in an action without the overhead of each dao call getting and then
freeing a connection from the pool. Also, transactions across DAOs are
much easier with the latter solutions too.
I don't have any links handy, but there's probably at least a
half-dozen pages about this on the Struts wiki that you can find at
http://struts.apache.org/
HTH,
-ed
On 3/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Is it a good idea to synchronize DispathAction to make sure all requests
to DB and results which come back don't overstep each other ?
Pls help.
Following is some detail of what am I doing in my application.
I have few operation I want to synchronize.
In my app following steps I am taking
1. calling dispatch Action getInstrumentsFromQ as under, Should
this be synchronized ?
public ActionForward getInstrumentsFromQ(ActionMapping
mapping, ActionForm form, HttpServletRequest request, HttpServletResponse
response) throws Exception {
..
..
}
2. In Dao service I have couple of lists which are stored as Class
variable, where I store one I received from DB.
public class InstrumentDiceQdao extends BaseDao implements
InstrumentDao{
private List instruments =(List )
Collections.synchronizedList(new ArrayList());
private List instrumentDbItems = (List)
Collections.synchronizedList(new ArrayList());
public synchronized List
getAllInstrumentsFromQ(Long sectorId) throws DiceWebException {
...
...
}
}
3. I am putting service object which has results of all DB query
in Session, so I can access from various places in web.
InstrumentService instService = new
InstrumentDaoService(ds) ;
try {
synchronized(instService)
{
List instruments =
instService.getAllinstrumentsFromQ(sectorId);
session.setAttribute(InstrumentService,instService);
}
}
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market
prices,
data and other information are not warranted as to completeness or accuracy
and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries
and affiliates.
--
The greatest tyrannies are always perpetrated in the name of the
noblest causes. Thomas Paine
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety - Benjamin
Franklin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
This has been a thread that has covered about 200 different emails from pillar to post, with the gurus and the outcasts all included. And you wish it would go away, you think it is a disservice. The present committers and their way of thinking or not thinking have in effect killed Struts and you think this is just spinning? If you keep thinking like this, you too will be a committer soon enough. snip On 3/21/06, Dave Newton [EMAIL PROTECTED] wrote: I _do_ believe that this thread, in some ways, is doing a disservice to the Struts umbrella. It's been disheartening in many ways, and I wish it would go away because for the most part we've been spinning over philosophical issues (perhaps we need a Struts and/or Jakarta and/or Apache meta-group). /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
LazyValidatorForm FormFile instantiation exception
Hi, I've got a form-bean definition like so: form-bean name=UploadForm type=org.apache.struts.validator.LazyValidatorForm form-property name=file type=org.apache.struts.upload.FormFile/ ... /form-bean When I load the page the first time, I get an instantiation exception: java.lang.InstantiationException: org.apache.struts.upload.FormFile It doesn't seriously affect the application, but I'm curious about the solution to this problem. I searched the [EMAIL PROTECTED] archives but didn't find this issue referenced. Is there some way to set an inital value to null? Maybe that would solve the problem? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
When I was young, when my dad would drive, the whole world of cars would be crazy and dangerous. When my mom would drive, everything changed. When you let people merge rather than try to cut them off, amazing things happen. The world changes. In this thread, Frank is like my dad and Jonathan is like my mom. My dad's defensive moves were in fact the cause of the problem. I basically have to agree with Jonathan on this one. On 3/21/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Jonathan Revusky wrote: I guess you and I think quite differently about certain things. In another part of this discussion, you mentioned malice as a reason not to give people commit access on an on-demand basis. However, this is something that hardly occurs to me as being much of a reason. In the above, you mention the idea that your secret voting mechanism could be cooked or people could suspect it is. This also never really occurred to me. I guess I just have a certain basic trust in the ethics of other open source people, and it does not occur to me that someone would cook the voting or that anybody would think that I would cook the voting. No question I tend to take a pessimistic view of things until I have reason to believe otherwise. I dare say all you have to do is look around the world and you will see more evidence to support that perspective than the more positive perspective. Sad, but I think true. But you say ...certain basic trust in the ethics of other open source people.. do you mean that you would allow anonymous, full commit privileges to anyone and everyone? In other words, a situation where anyone who wants to, whether they have ever seen the project before or not, can commit to the repository. This I absolutely think is a bad idea. A very bad one at that. But look, if somebody distrusts your ethics to that extent, why would they be in your community? I guess it could be more me expecting people to be expecting the worst of me :) Well, you know, it could also be that a public vote is preferred because project leaders are (at least vaguely) aware that if the vote is public people are less likely to disagree with them. (Of course, that is not exactly a legitimate reason.) That could be part of it, sure. But now, which one of us has the basic distrust issue here?? ;) LOL Well, if it comes into play at all, it should be considered. I would generally agree. Well, maybe (just maybe, I'm not really *so* presumptuous) the next step of evolution of your thinking is to move more towards implicitly trusting people. I mean: trust people to be acting in good faith until proven otherwise. Trust people to be at least moderately competent until proven otherwise. With the potential of major effort to clean up a corrupt source repository, I don't think you can do that. Just my opinion. In general, in this kind of collaborative internet model, don't you have to make a leap of faith and implicitly trust (until proven otherwise, of course) people you've never met? To some degree, yes. But what that degree is, well, that's where we don't completely agree :) I think there has to be *some* vetting that takes place, no matter how minor. Look at it this way... let's say you have 20 people actively working on a project, doing fantastic work. All of a sudden, you let the 21st person in, and they proceed to commit some less than stellar work, or maybe even break code because they don't yet have a good understanding of the project. Is that fair to the 20 others? Even if it can all be undone, is it fair for any of them to have to take the time to do so? I could quote Spock here, but I probably don't need to :) You see, what is the alternative? If you don't trust people by default, then how is trust established? I mean, this seems to be related to the catch 22 problem that you become a committer by contributing a lot, but it's practically impossible to contribute without being a committer in the first place, Craig never responded to this basic question. (Somehow, I suspect he won't.) But this is where the attitude of the committers (of any project, not talking Struts specifically here) comes into play. They have to be willing to accept contributions that don't come from themselves. If that is the case, a person can build up that trust and build up that reputation that leads to an invitation to join. One could even envision a situation where a person submits 10 things, none of them is accepted, and the person is still invited to join. That obviously would require the existing committers have a very open-mindedness about them, but it could happen. This serves your point of view and mine: there is a vetting process that I like, and there is a basic trust by default for you, maybe not quite to the degree you like, but I think its a reasonable compromise position. But the real problem here, that just
Re: has struts reached the saturation
Hello everyone. This thread has gone on way too long and quite honestly most of us are just basic Struts users who are still learning the framework. Various points have been made and all have their merits. Is it worth it to butcher each other over petty differences or to use our time wisely to make positive contributions? Thanks for listening. - Asad On Tue, 21 Mar 2006, Dakota Jack wrote: This has been a thread that has covered about 200 different emails from pillar to post, with the gurus and the outcasts all included. And you wish it would go away, you think it is a disservice. The present committers and their way of thinking or not thinking have in effect killed Struts and you think this is just spinning? If you keep thinking like this, you too will be a committer soon enough. snip On 3/21/06, Dave Newton [EMAIL PROTECTED] wrote: I _do_ believe that this thread, in some ways, is doing a disservice to the Struts umbrella. It's been disheartening in many ways, and I wish it would go away because for the most part we've been spinning over philosophical issues (perhaps we need a Struts and/or Jakarta and/or Apache meta-group). /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Are you trying to say that driving ISN'T dangerous and that there AREN'T tons of crazies on the road? Are you saying that defensive driving, as we were all taught growing up, isn't prudent? You must have never driven in New York if you don't think so :) There is a big difference between trying to work with people and ignoring the dangers in the world. Trying to avoid the dangers is good. In fact, I would submit that I am more like your mother: she obviously saw the same dangers your father did, but she chose to avoid them by working nicely with people rather than fighting them (I infer that your father was a fairly aggressive driver?). Frank Dakota Jack wrote: When I was young, when my dad would drive, the whole world of cars would be crazy and dangerous. When my mom would drive, everything changed. When you let people merge rather than try to cut them off, amazing things happen. The world changes. In this thread, Frank is like my dad and Jonathan is like my mom. My dad's defensive moves were in fact the cause of the problem. I basically have to agree with Jonathan on this one. On 3/21/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Jonathan Revusky wrote: I guess you and I think quite differently about certain things. In another part of this discussion, you mentioned malice as a reason not to give people commit access on an on-demand basis. However, this is something that hardly occurs to me as being much of a reason. In the above, you mention the idea that your secret voting mechanism could be cooked or people could suspect it is. This also never really occurred to me. I guess I just have a certain basic trust in the ethics of other open source people, and it does not occur to me that someone would cook the voting or that anybody would think that I would cook the voting. No question I tend to take a pessimistic view of things until I have reason to believe otherwise. I dare say all you have to do is look around the world and you will see more evidence to support that perspective than the more positive perspective. Sad, but I think true. But you say ...certain basic trust in the ethics of other open source people.. do you mean that you would allow anonymous, full commit privileges to anyone and everyone? In other words, a situation where anyone who wants to, whether they have ever seen the project before or not, can commit to the repository. This I absolutely think is a bad idea. A very bad one at that. But look, if somebody distrusts your ethics to that extent, why would they be in your community? I guess it could be more me expecting people to be expecting the worst of me :) Well, you know, it could also be that a public vote is preferred because project leaders are (at least vaguely) aware that if the vote is public people are less likely to disagree with them. (Of course, that is not exactly a legitimate reason.) That could be part of it, sure. But now, which one of us has the basic distrust issue here?? ;) LOL Well, if it comes into play at all, it should be considered. I would generally agree. Well, maybe (just maybe, I'm not really *so* presumptuous) the next step of evolution of your thinking is to move more towards implicitly trusting people. I mean: trust people to be acting in good faith until proven otherwise. Trust people to be at least moderately competent until proven otherwise. With the potential of major effort to clean up a corrupt source repository, I don't think you can do that. Just my opinion. In general, in this kind of collaborative internet model, don't you have to make a leap of faith and implicitly trust (until proven otherwise, of course) people you've never met? To some degree, yes. But what that degree is, well, that's where we don't completely agree :) I think there has to be *some* vetting that takes place, no matter how minor. Look at it this way... let's say you have 20 people actively working on a project, doing fantastic work. All of a sudden, you let the 21st person in, and they proceed to commit some less than stellar work, or maybe even break code because they don't yet have a good understanding of the project. Is that fair to the 20 others? Even if it can all be undone, is it fair for any of them to have to take the time to do so? I could quote Spock here, but I probably don't need to :) You see, what is the alternative? If you don't trust people by default, then how is trust established? I mean, this seems to be related to the catch 22 problem that you become a committer by contributing a lot, but it's practically impossible to contribute without being a committer in the first place, Craig never responded to this basic question. (Somehow, I suspect he won't.) But this is where the attitude of the committers (of any project, not talking Struts specifically here) comes into play. They have to be willing to accept contributions that don't come from themselves. If that is the case, a person can build
Re: has struts reached the saturation
Some will say it's not a good thing to do because of some peoples' perception of him, but I agree 100% with Dakota here! Threads like this are, I believe, absolutely necessary every now and again. The simple fact that everyone has gotten to voice their opinion, regardless of who agrees or disagrees, has been exactly what growing a community is all about. Your right, 99% of this has been philosophy debating. What's wrong with that? Philosophy is what open-source is based on, so why is it wrong to question the foundations every now and again? Hey, I'm a registered independent, but I voted for Bush this past election. Seemed like the right choice at the time. Is it wrong for me to now question what he says and does? Am I doing a disservice to the government by voicing my concerns and asking tough questions? Is it disheartening to confront differing ideas and ways of thinking? I don't know about anyone else, but if you answered yes to any of those questions, that silent noise you hear is the impending death of freedom of expression and democracy as a whole. Just because we're talking about open-source as opposed to political science doesn't mean the principals of freedom are any different. As long as everyone that posted here did so out of a desire to improve things, and by and large I personally believe that is the case, then this thread is relevant, appropriate and necessary. At least in my opinion. Frank Dakota Jack wrote: This has been a thread that has covered about 200 different emails from pillar to post, with the gurus and the outcasts all included. And you wish it would go away, you think it is a disservice. The present committers and their way of thinking or not thinking have in effect killed Struts and you think this is just spinning? If you keep thinking like this, you too will be a committer soon enough. snip On 3/21/06, Dave Newton [EMAIL PROTECTED] wrote: I _do_ believe that this thread, in some ways, is doing a disservice to the Struts umbrella. It's been disheartening in many ways, and I wish it would go away because for the most part we've been spinning over philosophical issues (perhaps we need a Struts and/or Jakarta and/or Apache meta-group). /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: has struts reached the saturation
+1 Jay | Jay Burgess [Vertical Technology Group] | http://www.vtgroup.com/ -Original Message- From: Asad Habib [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 1:28 PM To: Struts Users Mailing List Subject: Re: has struts reached the saturation Hello everyone. This thread has gone on way too long and quite honestly most of us are just basic Struts users who are still learning the framework. Various points have been made and all have their merits. Is it worth it to butcher each other over petty differences or to use our time wisely to make positive contributions? Thanks for listening. - Asad On Tue, 21 Mar 2006, Dakota Jack wrote: This has been a thread that has covered about 200 different emails from pillar to post, with the gurus and the outcasts all included. And you wish it would go away, you think it is a disservice. The present committers and their way of thinking or not thinking have in effect killed Struts and you think this is just spinning? If you keep thinking like this, you too will be a committer soon enough. snip On 3/21/06, Dave Newton [EMAIL PROTECTED] wrote: I _do_ believe that this thread, in some ways, is doing a disservice to the Struts umbrella. It's been disheartening in many ways, and I wish it would go away because for the most part we've been spinning over philosophical issues (perhaps we need a Struts and/or Jakarta and/or Apache meta-group). /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - 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: has struts reached the saturation
Frank W. Zammetti wrote: Some will say it's not a good thing to do because of some peoples' perception of him, but I agree 100% with Dakota here! Correction: I don't agree with him 100%... I don't believe Struts is dead, I think Struts is alive and well at the moment. There may be some things that can be done to keep it that way, some new ideas to consider, but I don't agree with Jack's characterization of its current state. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Dakota Jack wrote: The present committers and their way of thinking or not thinking have in effect killed Struts This obviously isn't true. I do agree that this thread is damaging in many ways, and that the thread even happened is a sign of something being wrong, misunderstood, or something else. and you think this is just spinning? Yep. For the most part this has been an exercise in mental masturbation. I don't believe much will come of this thread. Perhaps I'm wrong; we shall see. There are a few things that could stand some change. Mostly I see the same people saying the same things over and over, although perhaps providing additional clarity to those that care. I'm not saying the thread _shouldn't_ happen, I'm just saying I don't care much for it, even though I'm following it (somewhat haphazardly). If you keep thinking like this, you too will be a committer soon enough. That would be cool, although my current obligations leave me precious little time for recreational programming :( It was an anomaly that I saw this post as you got kill-filed after you threatened to sue me and contacted my boss following a pretty reasonable reply to a pretty ludicrous post. Don't talk to me like that episode didn't happen. 'Round _these_ parts, despite the valid points you make from time to time, you are persona non grata and on a very short list of people I genuinely dislike. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
FYI, this is my last post in this thread. I agree it has run its course, everyone had their say, and that's all that matters. Back to work I guess :) Frank Jay Burgess wrote: +1 Jay | Jay Burgess [Vertical Technology Group] | http://www.vtgroup.com/ -Original Message- From: Asad Habib [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 1:28 PM To: Struts Users Mailing List Subject: Re: has struts reached the saturation Hello everyone. This thread has gone on way too long and quite honestly most of us are just basic Struts users who are still learning the framework. Various points have been made and all have their merits. Is it worth it to butcher each other over petty differences or to use our time wisely to make positive contributions? Thanks for listening. - Asad On Tue, 21 Mar 2006, Dakota Jack wrote: This has been a thread that has covered about 200 different emails from pillar to post, with the gurus and the outcasts all included. And you wish it would go away, you think it is a disservice. The present committers and their way of thinking or not thinking have in effect killed Struts and you think this is just spinning? If you keep thinking like this, you too will be a committer soon enough. snip On 3/21/06, Dave Newton [EMAIL PROTECTED] wrote: I _do_ believe that this thread, in some ways, is doing a disservice to the Struts umbrella. It's been disheartening in many ways, and I wish it would go away because for the most part we've been spinning over philosophical issues (perhaps we need a Struts and/or Jakarta and/or Apache meta-group). /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - 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] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Frank W. Zammetti wrote: Your right, 99% of this has been philosophy debating. What's wrong with that? Philosophy is what open-source is based on, so why is it wrong to question the foundations every now and again? Who said it was wrong? I said _I_ wished the thread would go away because _I_ feel it has ceased to be useful and _I_ feel it's doing more harm than good at this point and _I_ feel that very little, if anything, positive will happen as a result. I am equally free to post that opinion. But now it's spun off on yet _another_ useless thread about the death of democracy and freedom because _I_ feel the thread has gone beyond the point of usefulness. You want a democracy on a national level move somewhere where there's proportional representation, direct elections, the amount of money one has to spend cannot alter voter perception, etc. You want a democracy on an open-source project level start your own. Oh, you did. Oh, wait, you have weighted votes. [...] but I voted for Bush this past election. Seemed like the right choice at the time. I can't even imagine a thought process that arrives at this conclusion, but that's yet another spin cycle. Is it disheartening to confront differing ideas and ways of thinking? No, it's disheartening to spin in circles. All done; you guys go ahead without me, I'll catch up with you on the technical side. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Frank W. Zammetti wrote: FYI, this is my last post in this thread. I agree it has run its course, everyone had their say, and that's all that matters. Well that was pretty much all I said, huh? +100 (I'm weighting _my_ vote higher because I was just a couple of classes shy of adding a philosophy major to my degree :) Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LazyValidatorForm FormFile instantiation exception
The basic LazyDynaBean implementation tried to be smart about instantiating objects - so that people's regular POJO beans would get automtaically created. In hindsight IMO this was a mistake. It is however easy to remedy - by overriding the createOtherProperty() method - see the 4. Automatic Property Instantiation section here: http://www.niallp.pwp.blueyonder.co.uk/lazydynabean.html So if you want you can create a custom LazyDynaBean with this behaviour. However, if you want this in LazyValidatorForm - you'll then need to plug that DynaBean implementation into your own LazyValidatorForm implementation - which is also pretty straight forward: http://www.niallp.pwp.blueyonder.co.uk/lazyactionform.html#section4 Niall On 3/21/06, David Durham [EMAIL PROTECTED] wrote: Hi, I've got a form-bean definition like so: form-bean name=UploadForm type=org.apache.struts.validator.LazyValidatorForm form-property name=file type=org.apache.struts.upload.FormFile/ ... /form-bean When I load the page the first time, I get an instantiation exception: java.lang.InstantiationException: org.apache.struts.upload.FormFile It doesn't seriously affect the application, but I'm curious about the solution to this problem. I searched the [EMAIL PROTECTED] archives but didn't find this issue referenced. Is there some way to set an inital value to null? Maybe that would solve the problem? Thanks, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
If it walks like a troll and talks like a troll [was: has struts reached the saturation]
Quite an interesting thread so far. There are certainly a lot of varying opinions. I would like to send a _BIG_ THANK YOU to all of you who have resisted the urge to respond to the useless troll drivel that continues to plague our community. http://wiki.apache.org/struts/DefineTroll http://wiki.apache.org/struts/DefinePita -- James Mitchell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: validwhen - Example not works properly
Valid when won't compare dates - you need to write your own custom validator to do this. Niall On 3/21/06, starki78 [EMAIL PROTECTED] wrote: Can someone give me a hint how to improve this example: I want to use this in that way assuring that one date is later than another: field property=DateTo depends=validwhen arg0 key=date.to/ var var-namevalid/var-name var-value(*this* DateFrom)/var-value /var /field - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Frank W. Zammetti wrote: Jonathan Revusky wrote: I guess you and I think quite differently about certain things. In another part of this discussion, you mentioned malice as a reason not to give people commit access on an on-demand basis. However, this is something that hardly occurs to me as being much of a reason. In the above, you mention the idea that your secret voting mechanism could be cooked or people could suspect it is. This also never really occurred to me. I guess I just have a certain basic trust in the ethics of other open source people, and it does not occur to me that someone would cook the voting or that anybody would think that I would cook the voting. No question I tend to take a pessimistic view of things until I have reason to believe otherwise. I dare say all you have to do is look around the world and you will see more evidence to support that perspective than the more positive perspective. Sad, but I think true. But you say ...certain basic trust in the ethics of other open source people.. do you mean that you would allow anonymous, full commit privileges to anyone and everyone? It is very unlikely that I would ever let anybody muck with the repository anonymously. For starters, while I think malice is quite rare in this case, the chances become much higher when you're talking about people who aren't taking the basic minimal responsibility of saying who they are. As a practical matter, the issue only will come up with people who have been on your mailing list and have some ideas and the subject of them becoming more involved comes up. In most (maybe all) cases I actually have been the one to bring it up. Basically, I'm arguing that being extremely liberal about giving people who shown some interest commit access is not nearly as dangerous as you are portraying it to be. I think the dangers of this kind of elitist closed club attitude that you see here are greater. In other words, a situation where anyone who wants to, whether they have ever seen the project before or not, can commit to the repository. This I absolutely think is a bad idea. A very bad one at that. Frank, isn't this a bit of a red herring? Who on earth who has not seen the project before *wants* to commit code? It really seems to me that you keep bringing up cases that have no relation to anything I recognize from my own experience as resembling reality. Again, the basic question we are discussing is subject to empirical verification. To keep talking, from first principles, about whether something is a good idea or not, when it can be tested empirically, is ultimately sterile. (I originally wrote masturbatory here, but find that too inflammatory...) It's like a bunch of ivory tower intellectuals having a theoretical debate about whether it's raining outside or not. Some illiterate janitor or somebody happens into the room, opens the window, sticks out his hand and says. Fellas, it's raining out there. Now, when I say this is empirically resolvable, I don't mean it's all that easy to run a well controlled experiment since each case will be different. However, here is the basic idea. You have one project that takes the elitist committers as high priesthood approach and another comparable project that has practically no barriers to entry (you do have to say what your name is but that should not be a big barrier.) You also have to be interested, but that's possibly a red herring because somebody who is not interested simply does nothing and never asks for commit access. The basic question is which project are you going to bet on in terms of it continuing to evolve and innovate? I don't know for absolutely sure, but in the experiment outlined above, given my thinking right now, I would bet my money on the project with low barriers to entry. While you can't run a perfectly controlled experiment, once you accumulate enough data points on this, you can start to, at least tentatively, draw some real conclusions. But look, if somebody distrusts your ethics to that extent, why would they be in your community? I guess it could be more me expecting people to be expecting the worst of me :) Well, you know, it could also be that a public vote is preferred because project leaders are (at least vaguely) aware that if the vote is public people are less likely to disagree with them. (Of course, that is not exactly a legitimate reason.) That could be part of it, sure. But now, which one of us has the basic distrust issue here?? ;) LOL Well, it's not comparable. That the project leaders would prefer to structure the voting in such a way that they tend to get their way is not the same as actually cooking the vote count or something. In any case, in my world view, it's normal that the people who did the lion's share of the work basically make the decisions, so I don't even see much problem with that. But my own suspicion is that
Re: has struts reached the saturation
On 3/20/06, Craig McClanahan [EMAIL PROTECTED] wrote: To be a meritocracy, more than the already elected committers would have to participate in the election. I'll be fascinated to watch you try to sell that approach to Apache at large :-). As I'm not a meritocracy evangelist, whether Apache agrees with me or not is not that important. I only called attention to an assertion that distorted the plain meaning of words. As societies become more intellectually sophisticated, this doublespeak becomes more prevalent. You don't see anybody claiming that they are running their community like a dictatorship; they all claim democracy, meritocracy and what not. But, as they say where I come from, tell me of what you brag about and I'll tell you what you lack. Out of the 22 existing committers to Struts, 21 of them followed the deal with it pattern and got voted in But, of course! As it is the only way... According to you, the owners of franchises in the NFL, or the NBA, also run their leagues as a meritocracy, because they follow rules very similar to yours, eh? That's the way Apache projects work. If you don't like it, you're free to run your own project, anywhere else you like, according to whatever rules you see fit. Wow, that's a relief! I thought you were going to forbid me to run my own project, anywhere else I like, according to whatever rules I see fit. From the way you respond it seems to me that you believe I object to the way your project is run. No, I object to the distortion of calling a meritocracy what is just a run-of-the-mill club. See above for evidence that an alternative really does exist. Not within your project structure, it doesn't. Which, by the way, is fine with me. Just don't misrepresent it, please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Frank W. Zammetti wrote: Are you trying to say that driving ISN'T dangerous and that there AREN'T tons of crazies on the road? Frank, there is a metaphor gap here anyway. We were discussing how dangerous it is to let anybody who wants to commit code do so. Now, you can restore the code repository to the exact same state it was in the past before the person's commits. In the case of driving, if you are seriously injured or killed in an accident, your body cannot be instantly restored to the state it was in before the accident. Dave Newton came up with a mountaineering analogy that suffers from basically the exact same metaphor gap, where he was talking about the context of a rock-climbing expedition for earning trust, making an implicit analogy with earning trust to be able to commit code. Can you seriously compare the risk of someone falling off a cliff with that of a temporary cock-up in the code repository? In software development, the fact that you can just back out the changes or restore the code from a previous snapshot in the worst cases, basically means that the risk-reward equation is nothing like it is in these other activities anyway. If that wasn't enough hyperbole, a nuclear meltdown simile was offered at some point too. There is such hyperbole in these comparisons that and, on the face of it, they basically are ridiculous. I don't think this is a consequence of bad faith. But I do attribute it to sloppy reasoning. Well, the other thing is cognitive dissonance. If you suddenly accept (even just temporarily for the sake of argument, let's say) that what I am saying is true, it means that all this Apache Way stuff and everything they have written about meritocracy is basically fatuous nonsense. And the implications of that, the cognitive dissonance, could be disturbing :-) Maybe I'm wrong about this, but it is an interesting hypothesis to explore, is it not? The idea that the barriers to becomming a committer serve absolutely no real purpose? As for people saying this shouldn't be discussed, it is not the ostensible topic of this list, but the discussion developed here. The people now complaining about this thread, it's not clear what their grievance is... If somebody is not interested, they don't have to read it... Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Internationalization - retaining data
I've implemented internationalization using Struts to use the application properties. If a user is entering some data on the form and decides to change the language to French, the form is reset which looses all the data they entered. Is there an elegant way to retain the data somehow? I know that because it does another request for my locale Struts action, it will forward to the page with the appropriate locale and properties being loaded. I've thought about putting the data on the current form as query string to the locale Struts action when it is called but that involves alot of work if it needs to be done for each page with a form. Any help or direction is appreciated. Thanks. Jade - Enrich your life at Yahoo! Canada Finance
Consequences of open commit privileges (was: has struts reached the saturation)
Jonathan Revusky wrote: I revert to my statement that a version repository makes it quite easy to restore the code to any point it was at in the past. In any case, consider some potential bad consequence of letting just about anybody commit: 1. On occasion, people start committing all kinds of bad code and it's a lot of work for you to start sorting it out. (This very rarely happens because new people are typically very timid in their initial commits, and don't do drastic things, their cokmmits are small and localized and could be rolled back easily.) 2. Once in a very long while, let's say 10 or 20 years, somebody with sociopathic tendencies comes along and... I dunno... starts introducing bugs deliberately. (But c'mon, this just about never happens.) Now, let's consider the consequences of making it very hard, nigh impossible, for new people to get involved. A talented, energetic person who has a fire in his belly to do some stuff is given the runaround. You drive that person away. You lose all the contributions he would have made. Moreover, that energy gets invested in the competing project (in our conceptual experiment above) with low barriers to entry. Which is going to be the bigger negative for a project, the above point, or points 1 and 2 above? There are other potential bad consequences than the two listed above. Consider 3. Subtle errors and exploitable security holes get introduced, either inadvertantly or intentionally. While a revision control system allows backing out changes, each change must be carefully considered. A security hole or other error may not be the result of a single change, but of multiple changes made in multiple locations and, perhaps, at multiple times. While open source allows a large number of eyes to see the code, it's not that easy to review code in depth and spot such problems. Much trust is placed on the skill, attention, and thoroughness of the committers. Consider the C2 Wiki and Wikipedia as analogies. Yes, it's easy to delete obviously false information. It's just as easy to reintroduce it. Keeping the worst of the cruft out is pretty much a full-time job for volunteers who take on the task, and there's not even agreement between them which is the cruft. Subtle or infrequently viewed incorrect information can, and does, remain for long periods of time. Spectacular failures occur that make headlines in the mass news media. I, for one, would never recommend to any business enterprise that they use Struts for important applications if the source was not vetted and controlled by a small, trusted committee. Your needs may not have such requirements for trustworthiness. But if businesses were to abandon use of Struts for important applications, would that be a reasonable trade-off for the contributions of your talented, energetic person? Or would the loss of talented, careful people, who needed a framework for business use where large sums of money are at risk, be a larger negative for the project? - George Dinwiddie http://www.idiacomputing.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Whoa, you guys are writers indeed ;) On 3/21/06, Jonathan Revusky [EMAIL PROTECTED] wrote: Frank W. Zammetti wrote: Jonathan Revusky wrote: Can you point out where Struts has utterly failed to compete with Webwork technically? I don't know either product so well in detail. My interest in Webwork and hence, Struts Action, is that FreeMarker is used very extensively there. But I don't think there's much onus on me to answer this question anyway. If the main Struts people want Webwork to be Struts Action 2.x, and for Struts 1.x users (at least the ones who want an action framework) to migrate to that, they are saying that WW is superior. The next few paragraphs is my own speculation, it is not based on hard facts, does not have any specific person(s) in mind, nor it means to judge any person(s). It is just my own feeling which may be well off base. While core Struts people are noticeably moving to JSF/MyFaces/Shale, the original Struts niche opens up for grabs. It could be left for the next best thing in action frameworks like WebWork or Stripes or Spring MVC or something else. But in the end the public perception would have been that Struts ran out of steam and lost the battle. Struts guys made a smart move bringing WebWork in as Struts 2.0. This way the name (the brand name if you like, but according to Tess Struts is not a registered trademark) is preserved and all that is related to the name is preserved too, not just software but people too. Check out the difference: I was a Struts committer once - Oh, that Struts that was 'zee standard', but it sucked and nobody wants it anymore and: I am a Struts committer - Oh, I've heard that version 2.0 is really cool. This way old Struts people retain their respectable status, while WebWork guys get the market. Very nice deal. Well, the responsible struts people threw in the towel, as far as a technical competition is concerned. They accepted that webwork was better. Now, if you think the boxer's manager threw in the towel prematurely, that could be an issue, but that he lost the fight is clear enough. The boxer is leaving the building. The boxer's manager is putting a fresh guy who is willing to pick up the fight. This corner will be covered, don't you get worried. The 1.3 branch brings a lot of power, but it almost feels superfluous with the pending WW merger (I have my suspicion that it hasn't gotten the attention it should have ever since the merger decision was made, but that's just my suspicion). Yes, but the WW merger came about specifically because Struts was falling further and further behind. At least this is what I infer. So maybe there is some confusion of cause and effect in all this. Afaik, changes for 1.3 branch were considered long ago before WebWork merger. They started to get implemented before merger, and some (a lot?) of people use 1.3 codebase right now. 1.3.x has to go official simply to ease managers' nervousness about using beta. I don't think there ever will be 1.4. At this point I don't see reasons for doing that. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Client Side Validation
Anyone have an example of using client side validation with a DynaValidatorActionForm ? I see no examples in here http://struts.apache.org//struts-doc-1.2.8/userGuide/dev_validator.html and while the javascript tag descrption is thorough: (http://struts.apache.org//struts-doc-1.2.8/userGuide/struts-html.html#javascript) I find it sort of useless outside of context. I am using the path attribute as the key in my validation.xml The form associated with the action is a DynaValidatorActionForm. html:form action = /FooLookupAction onsubmit=return validatefooLookupAction(this) // stuff here /html:form html:javascript formName=LookupAction / now I realize this syntax must be very wrong because I'm getting: ServletException: No form found under 'FooLookupAction' in locale 'en_US' I know that it is done one way if you use a normal ActionForm for and another way for DynaValidator* . I'm piuzzled as to why usage examples on the various permutations of client side validation have not yet slipped into the docs after all these years. Thanks in advance. Vinny -- Ghetto Java: http://www.ghettojava.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
On 3/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] I, for one, would never recommend to any business enterprise that they use Struts for important applications if the source was not vetted and controlled by a small, trusted committee. Your needs may not have such requirements for trustworthiness. In the case of the Apache Software Foundation, we do take intellectual property very seriously. Before receiving an account, each committer must file with the ASF a Contributor's License Agreement. In this way, when we make a commit, we legally donate the code to the ASF, which is a not-for-profit US corporation. It is the ASF's intention to have clear title to all the code in our repository, both for its benefit and for the benefit of the people who make use of ASF code. As the sole owner of the code, the ASF can also afford the individuals on the PMC some legal protection, since we act as agents of the ASF. We do encourage non-committers to submit patches, and we take care to credit each person's contribution in the repository log when we make the commit. Depending on the nature of the contribution, we may ask someone to file a CLA, even if he or she is not a committer. Many of the best features in Struts came from people who, at the time, were not committers. The Validator, for example, as well as Tiles. Features like the DispatchAction, roles-based authentification, declarative exception handling, among many others were contributed to the project by non-committers. Most recently, opt-in cancel handling came in as a patch from a non-committer, after a lengthy discussion of the best way to solve the problem. Many ideas went into the patch, contributed by committers and non-committer alike. * http://issues.apache.org/bugzilla/show_bug.cgi?id=38374 For more on contributiing to the project, see * http://struts.apache.org/helping.html Sadly, there are occasions when we cannot offter committer status to an individual. Usually, it is not because there is a problem with hsi or her code, but because all committers participate in the decision-making process. We don't have any peon-committers. Every committer is considered on track to become a PMC member, with a binding vote on releases and other matters. In turn, some committers and PMC members also become ASF members. The ASF members are the stakeholders of the corporation and elect the board of directors. While ASF projects have a reputation for voting, most decisions are made through informal discussions on the dev mailing list. Someone commits some code, and the rest of us peer-review the change (by following the commit list). Usually, that's the end of it, but any PMC member can veto a product change if need be. It's rare that a PMC member will abuse his or her veto power, but it does happen. On one occasion, the board did have to strip an individual's commit privileges. But, given that there are almost two thousand (2,000) ASF committers now, working on more than thirty top-level projects, that seems like a pretty good batting average :) We also take project management seriously. Every project has a designated Chair who is a vice-president of the foundation. The Chair/VP must tender a status report to the board on at least a quarterly basis, to be sure the project remains vital and collaborative. For more about how the ASF (and by extension Apache Struts) works, see * http://www.apache.org/foundation/how-it-works.html -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
hmm ... yes, isn't this struts-USER ... a place where users can discuss usage and maybe get a diamond from a developer occassionally ... isn't there a struts-DEVELOPER list for the assorted topics raised in this thread? Asad Habib wrote: Hello everyone. This thread has gone on way too long and quite honestly most of us are just basic Struts users who are still learning the framework. Various points have been made and all have their merits. Is it worth it to butcher each other over petty differences or to use our time wisely to make positive contributions? Thanks for listening. - Asad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
[EMAIL PROTECTED] wrote: Jonathan Revusky wrote: I revert to my statement that a version repository makes it quite easy to restore the code to any point it was at in the past. In any case, consider some potential bad consequence of letting just about anybody commit: 1. On occasion, people start committing all kinds of bad code and it's a lot of work for you to start sorting it out. (This very rarely happens because new people are typically very timid in their initial commits, and don't do drastic things, their cokmmits are small and localized and could be rolled back easily.) 2. Once in a very long while, let's say 10 or 20 years, somebody with sociopathic tendencies comes along and... I dunno... starts introducing bugs deliberately. (But c'mon, this just about never happens.) Now, let's consider the consequences of making it very hard, nigh impossible, for new people to get involved. A talented, energetic person who has a fire in his belly to do some stuff is given the runaround. You drive that person away. You lose all the contributions he would have made. Moreover, that energy gets invested in the competing project (in our conceptual experiment above) with low barriers to entry. Which is going to be the bigger negative for a project, the above point, or points 1 and 2 above? There are other potential bad consequences than the two listed above. Consider 3. Subtle errors and exploitable security holes get introduced, either inadvertantly or intentionally. First of all, pPeople seem to be addressing things I never said. For example, I don't think I ever said that people should be allowed to commit _anonymously_. I simply said that I believed you could be quite liberal about granting commit privileges to people and the sky would not fall in. Now, here you seem to be suggesting that I see no need for code review on new code that is committed. No, I certainly don't believe that. Of course, code that is committed should be reviewed carefully. However, I don't know if this is such a problem as regards this kind of situation. If you imagine a situationin which a new guy is given commit access, I think it's totally normal that the established developers will be quite carefully reviewing the things this guy does. So basically, I don't think your above point 3 is such an objection. Also, there is a countervailing point here: in terms of subtle errors and so on, simply getting more people involved may well reduce the number of such subtle errors for the basic principle of more eyeballs. So this works both ways. While a revision control system allows backing out changes, each change must be carefully considered. A security hole or other error may not be the result of a single change, but of multiple changes made in multiple locations and, perhaps, at multiple times. If you are going to go the route of drastically reduce the barriers to people committing code, you do need some people to keep an eye on this, sure. One aspect of this is that security holes can be introduced independently of whether you let in new committers or not. Now, of course, if the project simply stagnates because no new blood is allowed in, then no new security holes get introduced, but that is for the trivial reason that nothing is being done... period. But surely that's not your point, because that's kinda silly, right? While open source allows a large number of eyes to see the code, it's not that easy to review code in depth and spot such problems. Much trust is placed on the skill, attention, and thoroughness of the committers. Well, if you don't give somebody commit privileges and they offer a patch, and somebody has to review that patch, well, is that more work than if you give somebody commit privileges and they commit their patch and then it has to be reviewed? The argument that it is hard work to dilligently review code seems to be orthogonal to what we are talking about. Surely, in a well run project, code contributions would be reviewed carefully, right? So the contributed code needs to be reviewed in either case, right? And requires the same skill, attention, and thoroughness. Consider the C2 Wiki and Wikipedia as analogies. Yes, it's easy to delete obviously false information. It's just as easy to reintroduce it. Keeping the worst of the cruft out is pretty much a full-time job for volunteers who take on the task, and there's not even agreement between them which is the cruft. Subtle or infrequently viewed incorrect information can, and does, remain for long periods of time. Spectacular failures occur that make headlines in the mass news media. Just to be clear: are you speculating in the above, or are you speaking from direct experience maintaining such resources? I, for one, would never recommend to any business enterprise that they use Struts for important applications if the source was not vetted and controlled by a
Re: Consequences of open commit privileges (was: has struts reached the saturation)
On 3/21/06, Jonathan Revusky [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Consider the C2 Wiki and Wikipedia as analogies. Yes, it's easy to delete obviously false information. It's just as easy to reintroduce it. Keeping the worst of the cruft out is pretty much a full-time job for volunteers who take on the task, and there's not even agreement between them which is the cruft. Subtle or infrequently viewed incorrect information can, and does, remain for long periods of time. Spectacular failures occur that make headlines in the mass news media. Just to be clear: are you speculating in the above, or are you speaking from direct experience maintaining such resources? This happens all the time. Wikipedia is not the trusted place. It is just a place where you can look for quick description or links, but Wikipedia is unofficial. Also, I think that repairing one wiki page is a lot simpler than rolling back a CVS or SVN update of multiple interdependent source files. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
Michael Jouravlev wrote: On 3/21/06, Jonathan Revusky [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Consider the C2 Wiki and Wikipedia as analogies. Yes, it's easy to delete obviously false information. It's just as easy to reintroduce it. Keeping the worst of the cruft out is pretty much a full-time job for volunteers who take on the task, and there's not even agreement between them which is the cruft. Subtle or infrequently viewed incorrect information can, and does, remain for long periods of time. Spectacular failures occur that make headlines in the mass news media. Just to be clear: are you speculating in the above, or are you speaking from direct experience maintaining such resources? This happens all the time. I'll ask you the same question I asked of George: Are you speaking from personal experience maintaining wiki resources? I don't meant that sarcastically or anything. I just want to know, in these cases, whether people are sharing actual experiences with collaborative development of different types or are mostly just speculating. Wikipedia is not the trusted place. It is just a place where you can look for quick description or links, but Wikipedia is unofficial Also, I think that repairing one wiki page is a lot simpler than rolling back a CVS or SVN update of multiple interdependent source files. Well, it is still child's play compared to fixing up a person who fell off a cliff or was in a major automotive accident, or cleaning up after a nuclear meltdown. These were some of the incredible comparisons offered in this discussion. Despite the extreme kinds of comparisons like that, there are attempts here to portray what I am saying as unreasonable. But how unreasonable is it? Basically I am saying that you can drastically reduce the barriers to entry for new committers and the potential gains for the project far outweigh the risks. Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
On 3/21/06, Jonathan Revusky [EMAIL PROTECTED] wrote: Michael Jouravlev wrote: On 3/21/06, Jonathan Revusky [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Consider the C2 Wiki and Wikipedia as analogies. Yes, it's easy to delete obviously false information. It's just as easy to reintroduce it. Keeping the worst of the cruft out is pretty much a full-time job for volunteers who take on the task, and there's not even agreement between them which is the cruft. Subtle or infrequently viewed incorrect information can, and does, remain for long periods of time. Spectacular failures occur that make headlines in the mass news media. Just to be clear: are you speculating in the above, or are you speaking from direct experience maintaining such resources? This happens all the time. I'll ask you the same question I asked of George: Are you speaking from personal experience maintaining wiki resources? Yeah, usually political stuff. Old Pope - new Pope, for example. Despite the extreme kinds of comparisons like that, there are attempts here to portray what I am saying as unreasonable. But how unreasonable is it? Basically I am saying that you can drastically reduce the barriers to entry for new committers and the potential gains for the project far outweigh the risks. Why giving a commit priviliges to someone if you don't like (or haven't even seen) stuff that he brings in? Not to question does he really bring something in . Most project originators are dictators. They want to share and they want to use external force to move forward, but they want the project to reflect their ideas. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Consequences of open commit privileges (was: has struts reached the saturation)
Ted Husted wrote: On 3/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] I, for one, would never recommend to any business enterprise that they use Struts for important applications if the source was not vetted and controlled by a small, trusted committee. Your needs may not have such requirements for trustworthiness. In the case of the Apache Software Foundation, we do take intellectual property very seriously. Before receiving an account, each committer must file with the ASF a Contributor's License Agreement. In this way, when we make a commit, we legally donate the code to the ASF, which is a not-for-profit US corporation. It is the ASF's intention to have clear title to all the code in our repository, both for its benefit and for the benefit of the people who make use of ASF code. As the sole owner of the code, the ASF can also afford the individuals on the PMC some legal protection, since we act as agents of the ASF. Well, yeah... blah blah. Let's examine what this means in plain English. Correct if I'm wrong but I think the above means that to become a committer on an ASF project, you have to print off some document and you sign it and send it in by fax. Well, okay, fine. I previously suggested that the requirements for commiting code culd be that someone (a) has a name and (b) has expressed interest in working on the project. I append to those conditions that they (c) print off this thing and fax it in to ASF. Does this substantially change anything? Does it bolster or undermine any arguments made so far on this topic? Frankly, it seems like a big red herring. We do encourage non-committers to submit patches, and we take care to credit each person's contribution in the repository log when we make the commit. Depending on the nature of the contribution, we may ask someone to file a CLA, even if he or she is not a committer. Yeah, okay, so other people fax the thing in too. Fine. Now, in general, in this message, you're just repeating the theory, aren't you? But the problem is that many people in this conversation seem to believe that the theory isn't really working in practice. Moreover, the fact that Struts was unable to stay competitive with Webwork even given the huge advantages you should have in terms of attracting collaborators, this seems to suggest that your model did not work very well. Many of the best features in Struts came from people who, at the time, were not committers. The Validator, for example, as well as Tiles. Features like the DispatchAction, roles-based authentification, declarative exception handling, among many others were contributed to the project by non-committers. Most recently, opt-in cancel handling came in as a patch from a non-committer, after a lengthy discussion of the best way to solve the problem. Many ideas went into the patch, contributed by committers and non-committer alike. * http://issues.apache.org/bugzilla/show_bug.cgi?id=38374 For more on contributiing to the project, see * http://struts.apache.org/helping.html Sadly, there are occasions when we cannot offter committer status to an individual. Usually, it is not because there is a problem with hsi or her code, I don't get it. If somebody can donate worthwhile code, why shouldn't they be allowed to commit it? but because all committers participate in the decision-making process. We don't have any peon-committers. I don't really understand what you're talking about here, Ted. I can't refute it because I just don't understand it. I think I understood your first paragraph. I read that 3 times or so and my analysis of it boiled down to the fact that commmitters have to sign some legal boilerplate and send it in. AFAICS, that's practically a non sequitir; it's just a legal/procedural detail that isn't very relevant to the real issues in running a project, but I processed what you were saying, I think. This stuff about peon-committers, I just don't understand. Every committer is considered on track to become a PMC member, with a binding vote on releases and other matters. In turn, some committers and PMC members also become ASF members. The ASF members are the stakeholders of the corporation and elect the board of directors. So you are saying that the above means that somebody wants to hack the code, is able to hack the code, and can contribute, but because of the above, they can't become a committer. I really think you should expound the various logical steps of your argument more clearly. You know, it may seem clear in your own mind, but of course, your goal must be to convey your message to others. I can't understand your argument, and I'd say it's safe to say that if I don't understand it, other people probably don't either. Of course, only very few people who don't understand it have the self-confidence to say so forthrightly as I just did. You know, it's like the emperor's new clothes fable. While ASF projects have a reputation
Re: Consequences of open commit privileges (was: has struts reached the saturation)
Michael Jouravlev wrote: On 3/21/06, Jonathan Revusky [EMAIL PROTECTED] wrote: Michael Jouravlev wrote: On 3/21/06, Jonathan Revusky [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Consider the C2 Wiki and Wikipedia as analogies. Yes, it's easy to delete obviously false information. It's just as easy to reintroduce it. Keeping the worst of the cruft out is pretty much a full-time job for volunteers who take on the task, and there's not even agreement between them which is the cruft. Subtle or infrequently viewed incorrect information can, and does, remain for long periods of time. Spectacular failures occur that make headlines in the mass news media. Just to be clear: are you speculating in the above, or are you speaking from direct experience maintaining such resources? This happens all the time. I'll ask you the same question I asked of George: Are you speaking from personal experience maintaining wiki resources? Yeah, usually political stuff. Old Pope - new Pope, for example. Idle curiosity. Which site is that? Despite the extreme kinds of comparisons like that, there are attempts here to portray what I am saying as unreasonable. But how unreasonable is it? Basically I am saying that you can drastically reduce the barriers to entry for new committers and the potential gains for the project far outweigh the risks. Why giving a commit priviliges to someone if you don't like (or haven't even seen) stuff that he brings in? Well, I've already presented my views on this and this gets repetitious. All I can do is make the general comment that the reason to adopt a different approach would be that you recognize that the current approach is not really working. I grant that if you think everything is basically hunky dory, then there is no reason to change tack. Why fix what is not broken? So maybe it comes down to that. Is everything hunky dory? Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ FreeMarker group blog, http://freemarker.blogspot.com/ Not to question does he really bring something in . Most project originators are dictators. They want to share and they want to use external force to move forward, but they want the project to reflect their ideas. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
Heh, Frank. LOL At least this exchange has a bit more fun. My point was that in a real way the world WAS different because my mother changed it. She changed it by including in her space people my father would not trust. My father was not a really aggressive driver. He was convinced that others were. That was the problem. He couldn't see that they were not trying to run him off the road but just wanted to merge, even if they were a bit inept at doing that. The point follows: Very, very few people on the road are actually out to cause problems on purpose. The problem usually comes when someone wants to do something and another person thwarts them. Then things esculate quickly because they don't have the skill to deal with the problems of being thwarted gracefully. If you think you have to thwart them, you will engender unnecessary problems, even road rage. If you have a bit of trust and are able to get out of the way, you will engender courtesy and kindness. This is true in New York as well as Iowa. That is the point. The supposed worry about really evil people in open source is actually a failure to see how generous and how kind almost everyone, if not everyone, on these lists can be when involved in an interchange where they are valued. I admit to being more like my dad on many occasions on this list. I don't think my dad was a horrible person. I make some of the same mistakes I saw in him regularly. Maybe some day I won't. Anyway, I see a lot of my mom in Jonathan's approach. My experience is that it works better. On 3/21/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Are you trying to say that driving ISN'T dangerous and that there AREN'T tons of crazies on the road? Are you saying that defensive driving, as we were all taught growing up, isn't prudent? You must have never driven in New York if you don't think so :) There is a big difference between trying to work with people and ignoring the dangers in the world. Trying to avoid the dangers is good. In fact, I would submit that I am more like your mother: she obviously saw the same dangers your father did, but she chose to avoid them by working nicely with people rather than fighting them (I infer that your father was a fairly aggressive driver?). Frank Dakota Jack wrote: When I was young, when my dad would drive, the whole world of cars would be crazy and dangerous. When my mom would drive, everything changed. When you let people merge rather than try to cut them off, amazing things happen. The world changes. In this thread, Frank is like my dad and Jonathan is like my mom. My dad's defensive moves were in fact the cause of the problem. I basically have to agree with Jonathan on this one. On 3/21/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Jonathan Revusky wrote: I guess you and I think quite differently about certain things. In another part of this discussion, you mentioned malice as a reason not to give people commit access on an on-demand basis. However, this is something that hardly occurs to me as being much of a reason. In the above, you mention the idea that your secret voting mechanism could be cooked or people could suspect it is. This also never really occurred to me. I guess I just have a certain basic trust in the ethics of other open source people, and it does not occur to me that someone would cook the voting or that anybody would think that I would cook the voting. No question I tend to take a pessimistic view of things until I have reason to believe otherwise. I dare say all you have to do is look around the world and you will see more evidence to support that perspective than the more positive perspective. Sad, but I think true. But you say ...certain basic trust in the ethics of other open source people.. do you mean that you would allow anonymous, full commit privileges to anyone and everyone? In other words, a situation where anyone who wants to, whether they have ever seen the project before or not, can commit to the repository. This I absolutely think is a bad idea. A very bad one at that. But look, if somebody distrusts your ethics to that extent, why would they be in your community? I guess it could be more me expecting people to be expecting the worst of me :) Well, you know, it could also be that a public vote is preferred because project leaders are (at least vaguely) aware that if the vote is public people are less likely to disagree with them. (Of course, that is not exactly a legitimate reason.) That could be part of it, sure. But now, which one of us has the basic distrust issue here?? ;) LOL Well, if it comes into play at all, it should be considered. I would generally agree. Well, maybe (just maybe, I'm not really *so* presumptuous) the next step of evolution of your thinking is to move more towards implicitly trusting people. I mean: trust people
Is there a 'right' way to get a resource bundel given a JSP Page Context?
The Struts app I'm developing uses a number of customs JSP tags that we
have written oursevelves in an attempt to speed up repetative tasks and
to compltely remove the need for us to use Scriptlets which not nice to
have floating round your code. I developed a static helper function that
is used within our custom tags to get a MessageResources object given a
JspContext object and it worked perfectly while we only had one locale.
Today I got a translation of our resources.properties file in Irish for
the entire app and was horrified to see that when I added a
respources_ga.properties it was picked up perfectly by the standard JSP
tags but not by any of our custom tags. Below is the code for my
function, can anyone see where I am going wrong. Thanks a million,
Bart Busschots,
NUI Maynooth.
public static MessageResources getMessageResources(JspContext theJSPPage){
MessageResources resources = null;
String bundle = Globals.MESSAGES_KEY;
PageContext pageContext = (PageContext)theJSPPage;
if(resources == null) {
resources = (MessageResources)pageContext.getAttribute(bundle,
PageContext.REQUEST_SCOPE);
}
if(resources == null) {
ModuleConfig moduleConfig = getModuleConfig(pageContext);
resources = (MessageResources)pageContext.getAttribute(bundle +
moduleConfig.getPrefix(), PageContext.APPLICATION_SCOPE);
}
if(resources == null) {
resources = (MessageResources)pageContext.getAttribute(bundle,
PageContext.APPLICATION_SCOPE);
}
if(resources == null) {
throw new VTException(Failed to get Mesage Resources.);
}
return resources;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: has struts reached the saturation
That would not be an anomaly, Dave. If you think that my statement should have been taken as less than sardonic or even sarcastic, then you might be wrong. snip On 3/21/06, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: If you keep thinking like this, you too will be a committer soon enough. That would be cool, although my current obligations leave me precious little time for recreational programming :( It was an anomaly that I saw this post as you got kill-filed after you threatened to sue me and contacted my boss following a pretty reasonable reply to a pretty ludicrous post. Don't talk to me like that episode didn't happen. 'Round _these_ parts, despite the valid points you make from time to time, you are persona non grata and on a very short list of people I genuinely dislike. /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: Internationalization - retaining data
If the forward to the page with the appropriate locale and properties being loaded is a redirect, then the form can be kept in session scope to retain the input. The other trick would be to ensure that the command used to change the language to French submit to an action that uses a compatible ActionForm, so that it can capture the data. HTH, Ted. On 3/21/06, Jadeler [EMAIL PROTECTED] wrote: I've implemented internationalization using Struts to use the application properties. If a user is entering some data on the form and decides to change the language to French, the form is reset which looses all the data they entered. Is there an elegant way to retain the data somehow? I know that because it does another request for my locale Struts action, it will forward to the page with the appropriate locale and properties being loaded. I've thought about putting the data on the current form as query string to the locale Struts action when it is called but that involves alot of work if it needs to be done for each page with a form. Any help or direction is appreciated. Thanks. Jade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client Side Validation
The MailReader application for 1.3 uses DynaValidatorForm's. You could change those to DynaValidatorActionForm to test the syntax changes. * http://svn.apache.org/dist/struts/apps/v1.3.0/ HTH, Ted. On 3/21/06, Vinny [EMAIL PROTECTED] wrote: Anyone have an example of using client side validation with a DynaValidatorActionForm ? I see no examples in here http://struts.apache.org//struts-doc-1.2.8/userGuide/dev_validator.html and while the javascript tag descrption is thorough: (http://struts.apache.org//struts-doc-1.2.8/userGuide/struts-html.html#javascript) I find it sort of useless outside of context. I am using the path attribute as the key in my validation.xml The form associated with the action is a DynaValidatorActionForm. html:form action = /FooLookupAction onsubmit=return validatefooLookupAction(this) // stuff here /html:form html:javascript formName=LookupAction / now I realize this syntax must be very wrong because I'm getting: ServletException: No form found under 'FooLookupAction' in locale 'en_US' I know that it is done one way if you use a normal ActionForm for and another way for DynaValidator* . I'm piuzzled as to why usage examples on the various permutations of client side validation have not yet slipped into the docs after all these years. Thanks in advance. Vinny -- Ghetto Java: http://www.ghettojava.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. ** http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Has this thread reached it's saturation point yet?
My 2 cents. Struts is great. Struts pays my mortgage and allows my kids to go to a better private school. Most recently , struts upgraded my powerbook to a macbook pro. Honestly, I don't listen to the struts-haters anymore than I listened to the Apple-haters. Craig's invention was great, is great and will continue to be great for a while. I don't care if Craig makes a new framework based on mud pies, I'd still give the idea a respectful listen. The 2 people here that stir up the most arguments on list are beginning to buzz in my ears like misquitoes. Can't we just get back to the music? One thing I'd like to suggest though is this. Split this mailing list! I would love to have one list for the Action framework(s) and one for shale/JSF. Yeah I know I can procmail and google filter yadda yadda and I am doing that but it's a real PITA. I wonder which list the haters would subscribe to? -- Ghetto Java: http://www.ghettojava.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
javascript editor
Hi I have installed myeclipse 4.1 and eclipse 3.1.How to call javascript file from jsp.Any body knows sample file. kindly Regards gomes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client Side Validation
Also, you'll need to move the html:javascript tag inside the html:form tag. The reason you're getting an error looking up the form bean is because it only exists within the scope of html:form tag. Note that this requirement is generally true for form-based tag in the html taglib. L. Ted Husted wrote: The MailReader application for 1.3 uses DynaValidatorForm's. You could change those to DynaValidatorActionForm to test the syntax changes. * http://svn.apache.org/dist/struts/apps/v1.3.0/ HTH, Ted. On 3/21/06, Vinny [EMAIL PROTECTED] wrote: Anyone have an example of using client side validation with a DynaValidatorActionForm ? I see no examples in here http://struts.apache.org//struts-doc-1.2.8/userGuide/dev_validator.html and while the javascript tag descrption is thorough: (http://struts.apache.org//struts-doc-1.2.8/userGuide/struts-html.html#javascript) I find it sort of useless outside of context. I am using the path attribute as the key in my validation.xml The form associated with the action is a DynaValidatorActionForm. html:form action = /FooLookupAction onsubmit=return validatefooLookupAction(this) // stuff here /html:form html:javascript formName=LookupAction / now I realize this syntax must be very wrong because I'm getting: ServletException: No form found under 'FooLookupAction' in locale 'en_US' I know that it is done one way if you use a normal ActionForm for and another way for DynaValidator* . I'm piuzzled as to why usage examples on the various permutations of client side validation have not yet slipped into the docs after all these years. Thanks in advance. Vinny -- Ghetto Java: http://www.ghettojava.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. ** http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with character encoding.
Hi Dan, Both are on Windows. With best regards, Anjishnu. -Original Message- From: Dan Jas [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 9:45 PM To: Struts Users Mailing List Subject: Re: Problem with character encoding. Are you using WSAD on Windows and Tomcat on Unix/Linux? - Original Message - From: Anjishnu Bandyopadhyay [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Tuesday, March 21, 2006 5:51 AM Subject: Problem with character encoding. Hi all, I am generating a MS Word document through a JSP, by setting the JSP's content type as application/msword;. The .doc that is generated contains accentuated French characters (special French characters). I use Websphere (WSAD) to develop the code, but use Tomcat server for deployment final testing. In WSAD, the .doc file that is generated properly displays the special characters. But, in Tomcat, these characters are broken (distorted). The code snippet (in JSP) is as follows: %@ page language=java contentType=application/msword; charset=UTF-8 pageEncoding=UTF-8 % % String fileName = abc.doc; response.setContentType(application/msword); response.setLocale(java.util.Locale.FRENCH); response.setHeader(Content-Disposition,attachment;filename=+ fileName); % Can anyone give me some pointer, regarding the problem might be? Am I missing out something? Thanks for your time. With best regards, Anjishnu. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** - 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: Invalidating a session using JAVASCRIPT
Think the best way is call a sumit and do the clean up at the server.
What if cookies are used for maintaining session? - Then i belive we can
destory session at the client side by setting the time expiry on the
cookie. I am not sure though. If cookies are disabled, then session
maintenance happens with the jsessionId, then what happens in that case?
In that case i think the user can later, type in the URL with the
jsession id and access the page and he could get back to the session, if
it has not expired.
Can anyone clarify?
Thanks,
Vijay
[EMAIL PROTECTED] wrote:
Use
body onUnload=callAMethod()
...
/body
script
function callAMethod(){
submit to server(may be a servlet);
}
/script
I have not tested this by summiting to a servlet.But, I am sure
onUnload() works when you click on browser 'X;
Chandra
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 21, 2006 4:08 PM
To: Struts Users Mailing List
Subject: Re: Invalidating a session using JAVASCRIPT
Hi Sahil,
I believe this can be done by implementing the
HttpSessionBindingListenerInterface.The HttpSessionBindingListener
interface is implemented by the classes whose objects need to receive
notifications whenever they are added to or removed from a session. We
do not have to inform the container about such objects explicitly via
the deployment descriptor. Whenever an object is added to or removed
from any session, the container introspects the interfaces implemented
by that object. If the object implements the HttpSessionBindingListener
interface, the container calls the corresponding notification methods
Rajasekhar Cherukuri
Tata Consultancy Services Limited
Air-India Building 11th Floor,
Nariman Point ,
Mumbai - 400 021,Maharashtra
India
Mailto: [EMAIL PROTECTED]
Website: http://www.tcs.com
Sahil Gupta [EMAIL PROTECTED]
03/21/2006 04:08 PM
Please respond to
Struts Users Mailing List user@struts.apache.org
To
user@struts.apache.org
cc
Subject
Invalidating a session using JAVASCRIPT
Hi,
Can anyone tell me how to logout a user (invalidate his Session) when a
user directly closes his browser window.
Thanks.
Regards,
Sahil Gupta
Extn : 233
Email : [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
**
NetEdge Computing Global Solutions Private Limited.
A-14, Sector-7, NOIDA U.P. 201-301
Tel # 91-120-2423281, 2423282
Fax # 91-120-2423279
URL http//www.netedgecomputing.com
**
This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
ForwardSourceID:NT0001060A
Notice: The information contained in this e-mail message and/or
attachments to it may contain confidential or privileged information. If
you are not the intended recipient, any dissemination, use, review,
distribution, printing or copying of the information contained in this
e-mail message and/or attachments to it are strictly prohibited. If you
have received this communication in error, please notify us by reply
e-mail or telephone and immediately and permanently delete the message
and any attachments. Thank you
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--DISCLAIMER--
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and
all copies of it from your system, destroy any hard copies of it and
notify the sender. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient.
Lisle Technology Partners Pvt. Ltd. and any of its subsidiaries each
reserve the right to monitor all e-mail communications through its
networks.
Any views expressed in this message are those of the
individual sender, except where the message states otherwise and the
sender is authorized to state them to be the views of any such entity.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: javascript editor
script type=text/JavaScript src=/path/nameofjavascriptfile.js/ __ Senior Programmer Analyst, Tax Distributed Systems Development Tax Compliance Development, ADP IT Phone: (909) 592-6411 Ext. 3863 e-mail: [EMAIL PROTECTED] -Original Message- From: gomathi [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 21, 2006 7:56 PM To: user@struts.apache.org Subject: javascript editor Hi I have installed myeclipse 4.1 and eclipse 3.1.How to call javascript file from jsp.Any body knows sample file. kindly Regards gomes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invalidating a session using JAVASCRIPT
On 3/21/06, vijay venkataraman [EMAIL PROTECTED] wrote: Think the best way is call a sumit and do the clean up at the server. You'll likely want to do this in an onunload handler for the body element. What if cookies are used for maintaining session? - Then i belive we can destory session at the client side by setting the time expiry on the cookie. I am not sure though. If cookies are disabled, then session maintenance happens with the jsessionId, then what happens in that case? If the handler your submit invokes calls session.invalidate(), then it will not matter whether cookies or URL rewriting are used to maintain the session state. It will be removed from the server at that point, so any attempt to come in later will fail. In that case i think the user can later, type in the URL with the jsession id and access the page and he could get back to the session, if it has not expired. Can anyone clarify? That is why you will want to explicitly invalidate the session. Thanks, Vijay Craig
Re: Invalidating a session using JAVASCRIPT
Craig, Thanks for clarifying. Vijay Craig McClanahan wrote: On 3/21/06, vijay venkataraman [EMAIL PROTECTED] wrote: Think the best way is call a sumit and do the clean up at the server. You'll likely want to do this in an onunload handler for the body element. What if cookies are used for maintaining session? - Then i belive we can destory session at the client side by setting the time expiry on the cookie. I am not sure though. If cookies are disabled, then session maintenance happens with the jsessionId, then what happens in that case? If the handler your submit invokes calls session.invalidate(), then it will not matter whether cookies or URL rewriting are used to maintain the session state. It will be removed from the server at that point, so any attempt to come in later will fail. In that case i think the user can later, type in the URL with the jsession id and access the page and he could get back to the session, if it has not expired. Can anyone clarify? That is why you will want to explicitly invalidate the session. Thanks, Vijay Craig --DISCLAIMER-- This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Lisle Technology Partners Pvt. Ltd. and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can I execute js function from Struts Layout collectionItem tag?
Hello I want to execute js fuctions with collection property values as a parameters to this function. Is It possible with Struts Layout collectionItem tag? Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Actionform validate method
Is there a way to restrict the call to validate method. In below example manageaccount.jsp will be loaded initially by calling ManageLoad.do action mapping. validate=false is set as i dont need and validation when page loads first time. But later when i submit the form ,i need to validate form data and throw any ActionErrors in same page ,so i am calling Manage.do Experts ,is there any other better way to resolve such issue in struts1.2.8 version. --- action path=/Manage type=com.cdutc.cdpw.cdacs.action.CManageAction name=cManageForm scope=request input=/jsp/manageaccount.jsp parameter=method validate=true forward name=success path=/jsp/manageaccount.jsp / /action action path=/ManageLoad type=com.cdutc.cdpw.cdacs.action.CManageAction name=cManageForm scope=request parameter=method validate=false forward name=success path=/jsp/manageaccount.jsp / /action - Raghuveer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jsp with ajax
Hai In our project use jsp with ajax.How to include ajax technique in our project anybody knows in which tutorial follows this. any samples kindly regards gomes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jsp with ajax
This http://www.omnytex.com/articles/xhrstruts/ might help u. Kind regards, Rakesh Bhat PrimeSourcing(tm) The Global IT Services business from i-flex - Add Value Reduce Risk www.iflexsolutions.com/services/services.asp i-flex solutions limited - Bangalore Phone : +91(080) 5759-6873 Email : Rakesh.Bhat@ iflexsolutions.com -Original Message- From: gomathi [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 11:08 AM To: user@struts.apache.org Subject: jsp with ajax Hai In our project use jsp with ajax.How to include ajax technique in our project anybody knows in which tutorial follows this. any samples kindly regards gomes - 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: jsp with ajax
Use AjaxAnywhere tags.
That can be used both in jsp and jsf. That's very cool.
%@ taglib uri=http://ajaxanywhere.sourceforge.net/; prefix=aa %
body
script src=js/aa.js/script
script
ajaxAnywhere.formName = yourform;
/script
aa:zone name=area
Your area to be refresshed
/aa:zone
/body
script
ajaxAnywhere.getZonesToReload = function(url,submitButton) {
var frm=document. yourform;
if((frm.actioncondition.value!=SAVE)(frm.actioncondition.value!=CANCEL
)(frm.actioncondition.value!=INSERT)){
return area ;
}
}
ajaxAnywhere.formName = yourform ;
ajaxAnywhere.substituteFormSubmitFunction();
ajaxAnywhere.substituteSubmitButtonsBehavior(true);
/script
For instance validation you have write separate XMLHttpRequest to handle
this.
-Original Message-
From: gomathi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 22, 2006 11:08 AM
To: user@struts.apache.org
Subject: jsp with ajax
Hai
In our project use jsp with ajax.How to include ajax technique in our
project
anybody knows
in which tutorial follows this.
any samples
kindly regards
gomes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Greetings!
ICICI Infotech is now 3i Infotech.
The e-mail addresses of the company's employees have been changed to existing
name@3i-infotech.com. You are requested to take note of this new e-mail ID and
make use of the same in future
This e-mail message may contain confidential, proprietary or legally
privileged information. It should not be used by anyone who is not the original
intended recipient. If you have erroneously received this message, please
delete it immediately and notify the sender. The recipient acknowledges that 3i
Infotech or its subsidiaries and associated companies, (collectively 3i
Infotech), are unable to exercise control or ensure or guarantee the integrity
of/over the contents of the information contained in e-mail transmissions and
further acknowledges that any views expressed in this message are those of the
individual sender and no binding nature of the message shall be implied or
assumed unless the sender does so expressly with due authority of 3i Infotech.
Before opening any attachments please check them for viruses and defects.
