Re: Struts 2 protlet plugin. Validation errors.

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


Tim wrote:

Hi.
I have some errors while validating my form.

[b]struts.xml[/b]

 


/WEB-INF/jsp/view/addRequest.jsp
/WEB-INF/jsp/view/addRequest.jsp
/WEB-INF/jsp/view/ok.jsp



[b]AddClientRequestAction[/b]

public class AddClientRequestAction extends ActionSupport {
private String a = "a";
 
@Override

public String execute() throws Exception {
System.out.println("a: " + a);
 
 
if (isInvalid(a)) return INPUT;

addActionMessage("my action message");
return SUCCESS;
}
 
public String getA() {

return a;
}
 
public void setA(String a) {

this.a = a;
}
 
public void validate() {

System.out.println("AddClientRequestAction - VALIDATE!!!");
super.validate();
}
 
private boolean isInvalid(String value) {

return (value == null || value.length() == 0);
}
}

[b]Exception[/b]

2008-10-27 18:56:52,452 ERROR 
[org.jboss.portal.core.model.portal.control.page.DefaultPageControlPolicy] 
Rendering portlet window produced an error
javax.portlet.PortletException: Error executing action renderDirect

Caused by: javax.portlet.PortletException: org.apache.jasper.JasperException: 
java.lang.NullPointerException
at 
org.jboss.portal.portlet.impl.jsr168.api.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:91)
...
[b]interesting part[/b]

Caused by: java.lang.NullPointerException
at java.text.MessageFormat.applyPattern(MessageFormat.java:422)
at java.text.MessageFormat.(MessageFormat.java:350)
at 
com.opensymphony.xwork2.DefaultTextProvider.getText(DefaultTextProvider.java:70)
at 
com.opensymphony.xwork2.DefaultTextProvider.getText(DefaultTextProvider.java:111)
at 
org.apache.struts2.util.TextProviderHelper.getText(TextProviderHelper.java:62)
at 
org.apache.struts2.util.TextProviderHelper.getText(TextProviderHelper.java:105)
at org.apache.struts2.components.UIBean.evaluateParams(UIBean.java:631)
at org.apache.struts2.components.UIBean.end(UIBean.java:509)
at 
org.apache.struts2.views.jsp.ComponentTagSupport.doEndTag(ComponentTagSupport.java:42)
at 
org.apache.jsp.WEB_002dINF.jsp.view.addRequest_jsp._jspx_meth_s_005ftextfield_005f0(addRequest_jsp.java:200)
at 
org.apache.jsp.WEB_002dINF.jsp.view.addRequest_jsp._jspx_meth_s_005fform_005f0(addRequest_jsp.java:132)
at 
org.apache.jsp.WEB_002dINF.jsp.view.addRequest_jsp._jspService(addRequest_jsp.java:73)

[b]Extract from line 422 of MessageFormat.java as it is in Java 1.6.0_07:[/b]

for (int i = 0; i < pattern.length(); ++i) {

It seems that, struts 2 validator can't find message patterns. But i tried a great 
numbers of message mapping, and with out localized messages only 
addErrorMessage("error") method.

Could anyone help me with this error?
Thanks.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=497651&messageID=587399#587399



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2 Ajax DateTime Picker compatibility with FireFox 3

[Laurie Harper]

Abhinav Sharma wrote:

I am using inbuilt struts 2 ajax date time picker for my web application.  It
works fine with FireFox 2 but I face issues with rendering of these controls
in FireFox 3.  FireFox 3 is really unpredictable in rendering date picker
and time picker. Sometime it does not renders date picker or time picker or
both , some times every thing works fine.

Could you guys please suggest resolution to this issue.

Thanks,
Abhinav


Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts 2, dojo, cascade select fields

[Laurie Harper]

ReadOnly wrote:

Hi.. May be someone can help me:)..I start use struts 2.0.11, spring,
hibernate. I need create cascading select fields.. For example: first
select: city second select: streets .. When you are choosing city in the
first one select second one need show streets only for this city... I know
how such things work in asp.net, ajax... I read some information that I need
install and use dojo. I installes dojo and found an example, but don't want
work.. Please help me with example and with dojo. 
 Thank you...  


Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Known bug?

[Laurie Harper]

Marcelo Salhab Brogliato wrote:

Hi,
I'm using Struts 2 with Spring 2 and Hibernate.
Today I got something strange: I have an action that receive some 
parameters from post, and it was working fine. But when I put the 
annotation @Transactional in this action, it started getting NPE. The 
parameter was not being setted. Is this a bug or am I doing something 
wrong?

Just to knowledge, if I got the @Transaction out, the action works fine.

thanks for your time,
Salhab


Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 2.1.2 and JSON

[Laurie Harper]

Frans Thamura wrote:

hi alll

for S2 2.1.2, which will become beta

do this release make the JSON Plugins will be bundled and any idea for
JSON Plugins?


The JSON Plugin is an external project and I don't think there has been 
any discussion of bringing it into Struts. I'm afraid I don't understand 
the second part of your question.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: STRUTS with JSF

[Laurie Harper]

khalod85 wrote:

I've an application the first module is implemented by STRUTS and the second
module needs to be implemented by JSF I'm working with myEclipse as my IDE
and JBoss as a web server when I added the JSF capabilities to my project
and tried to launch the web application I noticed that the JBoss CPU history
is 100% and the application is not responding so what I need to do to avoid
this case and have my application working properly?


Usually I would say: Please post questions about using Struts to the 
Struts Users list only. The Struts Dev list is for discussing the 
development and enhancement of Struts itself.


However, this seems to be a JBoss issue rather than a Struts issue 
(especially since the problem occurred when adding JSF, not when adding 
Struts). So I'd suggest asking in a JBoss forum.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about GPL/Apache license compatibility ...

[Laurie Harper]

Laurie Harper wrote:

Giovanni Azua wrote:

hi,

I was researching a bit alternatives to dojo e.g. YUI or separate 
widgets like a tooltip developed and distributed under GPL license and 
found some comments from Struts contributors mentioning that because 
of those widgets being GPL they could not be considered ...


I am absolutely not an expert in the subject but having a project 
under GPL v3 (and researched and read a bit on it) one of the main 
advantages of v3 was the major revision that lead to compatibility 
with the Apache v2 license projects see 
<http://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv3-compatible_licenses> 
My question is then, would this mean that if e.g. a widget is 
distributed under GPL v3 it could be used and distributed with Struts 2?


Maybe it would be worthwhile to clarify this, as it could mean wider 
freedom of choice integrating existing GPL v3 projects with Struts ...


IANAL, but my reading of the FSF license compatibility discussion is 
that the ASF license is compatible with a project using GPLv3, *not* 
that GPLv3 is compatible with an ASF licensed project like Struts. In 
other words, GPL'd projects can now import ASF licensed libraries but 
ASF licensed projects still cannot use GPL'd libs.


It *is* possible that LGPLv3 may now be an acceptable license for 
dependencies, though. (I haven't looked at it to see if the 
objectionable clauses have been revised...)


This has probably been discussed on [EMAIL PROTECTED] already, and that is 
the correct place to get an ASF-wide policy change approved if it's 
appropriate.


L.


Update: the foundation's statement on license compatibility with the 
GPLv3 [1] appears to support my position, according to the definition of 
compatibility cited therein [2]. Notice that 'compatibility', by that 
definition, is not commutative: 'a compatible b' does not imply 'b 
compatible a'.


Note that the statement says the Apache License v2 is compatible with 
GPLv3, but *not* that GPLv3 is compatible with the Apache License.


I dug a little deeper, and found the work-in-progress policy covering 
this issue [3]. GPL and LGPL licensed libraries are explicitly excluded 
from being included in / distributed with Apache projects there, but it 
doesn't address the new (v3) revisions of those licenses.


A careful reading of that (draft) policy may give you an idea of whether 
(L)GPLv3 meets the requirements for use in ASF projects but, again, 
[EMAIL PROTECTED] is a better place to find guidance.


L.

[1] http://www.apache.org/licenses/GPL-compatibility.html
[2] http://www.fsf.org/licensing/licenses/compat.html
[3] http://people.apache.org/~rubys/3party.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: about GPL/Apache license compatibility ...

[Laurie Harper]

Giovanni Azua wrote:

hi,

I was researching a bit alternatives to dojo e.g. YUI or separate 
widgets like a tooltip developed and distributed under GPL license and 
found some comments from Struts contributors mentioning that because of 
those widgets being GPL they could not be considered ...


I am absolutely not an expert in the subject but having a project under 
GPL v3 (and researched and read a bit on it) one of the main advantages 
of v3 was the major revision that lead to compatibility with the Apache 
v2 license projects see 
 
My question is then, would this mean that if e.g. a widget is 
distributed under GPL v3 it could be used and distributed with Struts 2?


Maybe it would be worthwhile to clarify this, as it could mean wider 
freedom of choice integrating existing GPL v3 projects with Struts ...


IANAL, but my reading of the FSF license compatibility discussion is 
that the ASF license is compatible with a project using GPLv3, *not* 
that GPLv3 is compatible with an ASF licensed project like Struts. In 
other words, GPL'd projects can now import ASF licensed libraries but 
ASF licensed projects still cannot use GPL'd libs.


It *is* possible that LGPLv3 may now be an acceptable license for 
dependencies, though. (I haven't looked at it to see if the 
objectionable clauses have been revised...)


This has probably been discussed on [EMAIL PROTECTED] already, and that is 
the correct place to get an ASF-wide policy change approved if it's 
appropriate.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Issue WW-2107 question - Is JSTL disable or not?

[Laurie Harper]

Felipe Rodrigues wrote:

Hi guys,

Sorry, but it is not quite clear for me if the JSP EL is disable in struts2
tags or not. I'vev seen that static methods calls is disabled.


As of Struts 2.0.11 yes, EL expressions are disabled in Struts tags.

In future, please post questions about using Struts to the Struts Users 
list only. The Struts Dev list is for discussing the development and 
enhancement of Struts itself.


http://struts.apache.org/mail.html

If you'd like to follow up, please do so there.

Thanks,

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts tags and Filter Dispatcher Url Pattern-struts 2.1.1

[Laurie Harper]

[The answer to your question is yes, Struts tags will only work within 
the context of a request processed by Struts (i.e. through the filter). 
However, in the future:]


Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

Sanjeev Vijapurapu wrote:

Hi,

I have recently upgraded to struts 2.1.1 and if my struts filter
dispatcher url pattern is not "/*" instead it is "/actions/*,
/struts/*".

And now if I am trying to access a jsp page that is not under that url
pattern ( something like /test.jsp), struts tags in that jsp page fail.

I get the following stack trace

 


java.lang.NullPointerException
at
org.apache.struts2.views.jsp.TagUtils.getStack(TagUtils.java:55)
at
org.apache.struts2.views.jsp.StrutsBodyTagSupport.getStack(StrutsBodyTag
Support.java:46)
at
org.apache.struts2.views.jsp.ComponentTagSupport.doStartTag(ComponentTag
Support.java:47)
at
org.apache.jsp.test_jsp._jspx_meth_sx_head_0(org.apache.jsp.test_jsp:95)
at
org.apache.jsp.test_jsp._jspService(org.apache.jsp.test_jsp:65)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:93)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:373)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:470)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:364)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 
So does this mean that if my jsp is using struts tags, it has to go

through filter dispatcher?
 
Thanks


 






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XSS and the "encode" attribute of

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

GF wrote:

Can someone explain me the use of the "encode" attribute of  ?

I'm trying to do something like this:




http://localhost:8080/myTest/content/hello.action?>'">alert(document.cookie)

But.. when it output the  it doesn't encode the query string
and this cause the Javascript being executed and all the XSS risks
related to this.
I'm trying this code with Struts 2.0.11

Is it normal?!

And.. I have taken a very quick look into the class:
org.apache.struts2.components.URL revision 595746
There is the "encode" properties.. the getters and setters.. but where
is it checked and the URL encoded?

Maybe I'm just wrong and I'm missing to do something banal.
Anyone can give me an hint?

Thank you!
GF



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Running Struts 2.0.11 on Weblogic 8.1 SP5

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

LesleyT wrote:

Hi all,

Am trying to run our application built using:
Struts 2.0.11, Spring 2.0, Hibernate 3.2 on WL 8.1 sp5.

I've read that some people have successfully run a struts2 app on weblogic
and would like to know how you got it up and running.

I retrotranslated the JARs below:
xwork-j4-2.0.4.jar
struts2-core-j4-2.0.11.jar
struts2-spring-plugin-j4-2.0.11.jar
ognl-j4-2.6.11.jar
freemarker-2.3.8.jar

Are there any other JARs you need to J4 for WL 8.1 ?

But for some reason I don't get consistent errors coming from the
application. 


I've had a couple of issues which don't happen consistently on my weblogic
deployed war files:
* spring's contextloaderlistener not loading any beans
* parse exceptions when the xmlconfigurationprovider parses the
struts-default.xml 
* null pointer exceptions when our app uses struts tags


Does anyone hav any advice on how they got their app working on weblogic 8.1
?

Thanks,
Lesley



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts Token help

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

Indresh Chadha wrote:

Hi,

I need to stop:
1. multiple post to an action
2. refresh of a page
using Struts.

What i tried was using the Struts Token.
I have a common BaseAction class that extends Action class. All the other
action classes extend the BaseAction class.

In my BaseAction class I did the following:
1. public static boolean blnFirst = true;
2. In execute method:
  if(blnFirst){
 System.out.println("BaseAction: FIRST Time");
saveToken(httpRequest);
this.blnFirst = false;
  }

Saving the token adds an attribute:
org.apache.struts.Globals.TRANSACTION_TOKEN_KEY in the session
Now when I try to check the validity of the token by
isTokenValid(httpRequest), it is everytime resolving to NULL.
This piece of code:
httpRequest.getSession().getAttribute(Globals.TRANSACTION_TOKEN_KEY) returns
some value only the first time.All the other time it returns null.

Do I need to save the token every time? (Which I dont think so) OR just
once(which I'm doing) OR is there any other way?
I'm resetting the token every time using resetToken(httpRequest).

Please help me out.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Result types for S1

[Laurie Harper]

Frank W. Zammetti wrote:

Hi Antonio,
Antonio Petrelli wrote:

2007/12/13, Frank W. Zammetti <[EMAIL PROTECTED]>:

return mapping.findForward("JSONResultType");


I don't like this syntax, because it mixes the concept of forward (to a
page) with the rendering of the ActionForm. Probably a more specific
ActionMapping method, or different types of ActionForwards, could be 
better.


So you'd rather see something like:

return mapping.renderResult("JSON");


Or stick with mapping.findForward(something) but provide a mechanism for 
mapping that result type to the appropriate (JSON/XML/etc) rederer in 
struts-config.xml. That would eliminate any concern over clashes with 
existing action return strings (small though the risk is), and would be 
consistent with existing declarative semantics.


With that, it could be easy to make the 'result providers' such as JSON 
serialization, XML serialization and so forth plugable/configurable 
and/or parameterizable.


For example:

  


  

...

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Disable validate interceptor while executeAndWant in "wait" phase

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

Igor Vlasov wrote:

Hello.

I recieve an validation exception while "wait" phase of executeAndWant.

My example:

1.



longRunningAction-wait.jsp
longRunningAction-success.jsp




2. longRunningAction-wait.jsp

<%@ taglib prefix="s" uri="/struts" %>

  
Please wait
!!!!// without 
  
  
Please wait while we process your request.
   
  




3. An long running action. LRAction

At first time, when i post data to LRAction, it does validation and start a
"background process" and display a "wait page".  then it calls LRAction in
refresh action and do not use any paramemers. This invoke validatotion and
therefore validatotion error.


I suggest to disable validation while "wait" phase is active.  
Therefore we may not use 
includeParams="all" />"/>.









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Indexed and Nested properties

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

L.

Radha Krishna wrote:

Hi,
   
i am working on indexed,nested properties. i have following entries in my ActionForm
   
   
  private ArrayList countryNames = new ArrayList();
  
public void setCountryNames(int index,LabelValueBean val) {
this.countryNames.add(index,val); 
}
   
   
  public LabelValueBean getCountryNames(int index){

while(index>=this.countryNames.size())
this.countryNames.add(new LabelValueBean("label","value"));
return (LabelValueBean) this.countryNames.get(index);
  }
   
  i am writing code in JSP like this,
   
  

 
   
  
   
  after execution i am getting the source like 
   



  

  ..
   
  but when i click on my submit button, setter method never get called, it calls getter method properly for all text boxes
   
  Can anyone please tell me what could be the problem and how solve this.
   
  Thanks.
   
   

   
-
Boardwalk for $500? In 2007? Ha! 
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: s:include tag

[Laurie Harper]

Sairam01 wrote:

I'm unable to include a jsp dynamically. The include tag doesn't evaluate
VALUE the expression.



someName is a attribute on my action code. Should this work..?



Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Mapping select multiple to collention

[Laurie Harper]

jpedro wrote:

Hi,
I have this code in my jsp:


  


the property oList is a typed List in the form and it works fine.
The problem is that i can only map the property selectedList to an array. 
I wold like to map this property to a List or a Set. Is that possible?


Thanks, 
JP


Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OGNL and JSP 2.1 - are there plans to fix?

[Laurie Harper]

mraible wrote:

On another note (to quote the article above):


With version 2.1 or later, the character sequence #{ represents a deferred
expression, assuming the attribute has been declared to support deferred
expressions in the TLD. If the attribute does not support deferred
expressions, then the presence of the #{ character sequence results in a
translation error.


This seems to imply that if Struts produced a JSP 2.1 TLD for its tags, it
could turn off the support of #{} on a per-attribute basis.


Yes, but that wouldn't help much if it just results in translation errors...

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: radio Button in Struts2

[Laurie Harper]

merryba wrote:

Hi,

Please I am newbie to Sruts2.
I want the radio button to display "Male" as the default one.




How can I do it? Please help me.

Thanks


Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Please help, donot validate a field when cancel button is click

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

[a hint re. your problem: see the html:cancel tag.]

L.

cvu wrote:

Hi Gurus, please help
Scenario:By pass the validation when cancel button is click.
  I have a start.jsp that has a text field required to be filled and 2
buttons Cancel and submit. The submit button is click I forward it to
finish.jsp but if the cancel button is click then go to welcome.jsp. Right
now if the text field is filled then it go to finished.jsp if it is not
filled then error msg will post next to it. However, when I click the Cancel
button - type button, it requires text field has to be filled but I want to
by pass the validation (why I have to fill up the field when I click the
cancel button?)

I have a validation.xml file like this:





maxlength
24

 



And the start.jsp like this:


:







and the 2 buttons - Cancel is button type, other is Submit type like this:





 






Please help 
many thanks





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Replacing WebMacro

[Laurie Harper]

Gerardo Corro wrote:

Hi,

I'm in the middle of replacing an old application written with WebMacro in the 
presentation layer, our team is thinking about struts like the MVC to be used, 
however we wonder what could be used besides Struts in order to create nice 
GUIs as the ones you can create with WebMacro in the view layer.

Thanks!
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=100309&messageID=168893#168893


Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: newbie: struts 1.2

[Laurie Harper]

ojasrege wrote:

As part of an ActionForward.execute(), I am forwarding to a JSP page using a
global forward name.

The jsp page corresponding to the global forward is called.  However, its
form validate() and ActionForward.execute() methods are called before the
jsp page is displayed.

Is this normal?

Do I have a setting wrong somewhere?


Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: javacript and logic:forward

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


thenameless20 wrote:

What comes firsta documents 

or



Is this browser dependent?

For more backgound: 
The login for my site uses a cookie value, this cookie was created on the
same domain but not in 
the java request, so if I'm correct javascript is probably the only solution

I have to reading in this
client's cookie

my javascript reads the client cookie sets a hidden form variable and using
`AJAX` like magic it sends
the forum to a method that stores that cookie's value in the http servlet
response, so it can use it
later on, after this my hopes are for the logic forward to trigger and
continue the login process.

This method works from what I've tested, but seems finicky using different
browsers...is this method I described a solid way to approach this problem?



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to set label position with a select tag

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

TonyD wrote:

Hi,

Someone knows how to set a blank before a label of a select tag?

 State:
and not
State:  


the label value is read from a configuration file

And more, how to have the label without the ":" character?

 State

Thanks for a kindly reply!



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Null pointer exception in action class - file upload form file problem URGENT!!! HELP

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

vbharath19 wrote:

Hi,

I have a jsp from which i upload a file. this field is of Formfile type.

jsp entry:

action="/pages/deploy-action.do" >

 


	   
 




I have not used bean:define in the jsp. when i use it,it throws cannot
assign null exception.

in the struts config xml, entries are present for form - bean but not for
its property, i tried entering the property, it did not make a difference

I am using the multiform/form-data enctype and also method=post. 


when i run the page and upload the file and invoke the action class i get
the following error.

java.lang.NullPointerException
at actions.DeployAction.execute(DeployAction.java:139)
at
org.apache.struts.action.RequestProcessor.processActionPerform(Reques
tProcessor.java:419)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.ja
va:224)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:119
6)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] struts-tags.tld broken

[Laurie Harper]

James Holmes wrote:

It appears that the generated struts-tags.tld file is broken in the 2.0.8, 2.0.6
and possibly other builds. The URI being generated and used inside the
 tags should be "http://struts.apache.org/tags"; instead of
"/struts-tags" unless I'm confused. Also, the  value seems to have
unnecessary quotation marks:


  2.2.3
  1.2
  s
  /struts-tags
  "Struts Tags"





Should I open a JIRA issue?


In what way is anything 'broken'? While using a full URL might be more 
conventional, the simple URI that's in place today is perfectly valid. 
Changing it would break every existing application with little or no 
benefit IMHO. The quotes in the display name are unnecessary, but 
harmless I think.


Are these issues causing you problems somehow?

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: java.lang.IllegalArgumentException: No bean specified

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

L.

Vijay KS wrote:

onfig














my first jsp is FileUpload.jsp like this
-


Upload File

after clicking the Upload file button, the uploadSuccess.jsp looks like this








The correspondin form beans are

public class StrutsUploadForm extends ActionForm
{ //assume all the methods are publlic
FormFile theFile;
ArrayList objectList;
valueObject valueObj;

FormFile getTheFile() {
return theFile;
}
void setTheFile(FormFile theFile) {
this.theFile = theFile;
}
void setValueObj(valueObject valueObj){
this.valueObj = valueObj;
}
valueObject getValueObj(){
return this.valueObj;
}
void setObjectList(ArrayList objectList){
this.objectList = objectList;
}

ArrayList getObjectList(){
return this.objectList;
}
}

my value Object is

public class valueObject
{
String id;
String firstName;
String lastName;
String fullName;

valueObject(String id,String firstName,String lastName){
this.id = id;
this.firstName = firstName;
this.lastName = lastName;
}
void setId(String id){
this.id=id;
}
String getId(){
return this.id;
}
void setFirstName(String firstName){
this.firstName = firstName;
}
String getFirstName(){
return firstName;
}
void setLastName(String lastName){
this.lastName = lastName;
}
String getLastName(){
return lastName;
}
getFullName(){
return firstName+lastName;
}
}

and my action class is

public class StrutsUploadAction extends Action
{
public ActionForward execute(..){
StrutsUploadForm myForm = (StrutsUploadForm)form;

if(!"show".equals(request.getParameter("parameter"))){
valueObject v1 = new valueObject("3","Babu","Prasad");
myForm.setValueObj(v1);
ArrayList valueList = new ArrayList();
valueList.add(new valueObject("1","vijay","ks"));
valueList.add(new valueObject("2","Ram","Kumar"));
valueList.add(v1);
valueList.add(new valueObject("4","Raju","sundaram"));
valueList.add(new valueObject("5","Kamal","Batch"));
valueList.add(new valueObject("6","Ragu","varan"));
myForm.setObjectList(valueList);
}else{
System.out.println("myFORM OBJECTS "+myForm.getValueObj().getId());
}

return mapping.findForward("success");
}
}


But i try to select one of the value form the combo box and submit the
uploadsuccess.jsp ,i am getting the following error

type Exception report

message

description The server encountered an internal error () that prevented it
from fulfilling this request.

exception

javax.servlet.ServletException: BeanUtils.populate
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1254)
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:821)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)

root cause

java.lang.IllegalArgumentException: No bean specified
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptor(PropertyUtils.java:837)
org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:934)
org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808)
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:1252)
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:821)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:254)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: struts-faces integration problem with existing struts based application?

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

vijendra wrote:

I am trying to integrate struts-faces in my previous struts based
application.
i am unable to get required results.

the libraries i am using are:-(mainly)
commons-beanutils-1.7.0,
commons-chain-1.1,
commons-digester-1.8,
commons-lang-2.3,
struts-faces-1.3.8,
tomahawk-1.1.5,
log4j-1.2.8,
myfaces-api,
myfaces-impl,
struts,
struts-el-1.3.8,
struts-taglib-1.3.8,
struts-extras-1.3.8,

and many more.
i feel these are the responsible files which are really required to
be there.

Now what i did is configured web.xml with faces settings.
configured faces-config.xml.

when i modified web.xml for faces integration and calling a page from
some other page giving extention as faces to my new page either it
gives me exception.or sometimes it comes as many templets shown in
loop(one in other and so on:- useless) but original content is not
shown.
Exception is :
javax.faces.FacesException: javax.servlet.jsp.JspException:
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:
422)

and if i try using /faces/* combination it dosen't comes out at all.
(In this case my doubt is its unable to find out the page itself)

But when i am calling a particular jsp page(reporthome.faces) which
was earlier normal jsp from index page.i modified this page with
struts-faces libraries with what i require.
but it first of all loads very slowly , sometime shows the same page
in looped condition so upper tags are getting displayed many times and
other data is gone.
and finally it comes up with exception
javax.faces.FacesException:
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:
422)

this exception comes in many different situation but comes mostly.
so what is the reason behind.

please guide me. thanks

vijendra
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=84385&messageID=151283#151283



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Little problem with filter paramssetter

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

Alexey wrote:
In JVM setted locale ru_RU. Decimal separator `comma` (,). Struts 2.0.6, Tomcat 5.5.17, JBoss 4.0.4 GA with EJB 3 


Code:
System.out.println("TIME: " + 
ServletActionContext.getRequest().getParameter("timeWork").getClass());
System.out.println("TIME: " + 
ServletActionContext.getRequest().getParameter("timeWork"));
 then ...
System.out.println("TIME: " + 
ServletActionContext.getRequest().getAttribute("timeWork").getClass());
System.out.println("TIME: " + 
ServletActionContext.getRequest().getAttribute("timeWork"));

When i post form on server in different browsers occurs next.
IE:
14:21:25,890 INFO [STDOUT] TIME: class java.lang.String
14:21:25,890 INFO [STDOUT] TIME: 2,5

14:21:25,906 INFO [STDOUT] TIME: class java.lang.Double
14:21:25,906 INFO [STDOUT] TIME: 2.5

FF:
14:32:31,750 INFO [STDOUT] TIME: class java.lang.String
14:32:31,750 INFO [STDOUT] TIME: 2,5

14:21:25,906 INFO [STDOUT] TIME: class java.lang.Double
14:21:25,906 INFO [STDOUT] TIME: 25

Other if I type 2,5 whith dot (2.5):
IE:
14:21:25,890 INFO [STDOUT] TIME: class java.lang.String
14:21:25,890 INFO [STDOUT] TIME: 2.5

14:21:25,906 INFO [STDOUT] TIME: class java.lang.Double
14:21:25,906 INFO [STDOUT] TIME: null

FF:
14:32:31,750 INFO [STDOUT] TIME: class java.lang.String
14:32:31,750 INFO [STDOUT] TIME: 2.5

14:21:25,906 INFO [STDOUT] TIME: class java.lang.Double
14:21:25,906 INFO [STDOUT] TIME: 2.5

Can you say why params so different in different browsers?
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=83515&messageID=149483#149483



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AutoComplete Option turn off in struts 1.1

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html


Tirumalasetty, Jyotsna (Consultant) wrote:

Hi,

 


I am developing an application in which I have to turn off autocomplete
option for entering email Id and retype Email Id. 

 


I wrote a custom tld for text tag  to make autocomplete option turn
off..

 


Unfortunately I am using struts 1.1 which is does not support the
method..

 


This is my code

public class TextTag extends org.apache.struts.taglib.html.TextTag {
   protected String autocomplete;
  public String getAutocomplete() {

return autocomplete;

}

public void setAutocomplete(String autocomplete) {
 
this.autocomplete = autocomplete;
 
  }
 
public void prepareOtherAttributes(StringBuffer sb) {
 
if (autocomplete != null) {
 
sb.append(" autocomplete=\""+autocomplete+"\"");


}

}

}

 

 


when I view source I am not able to see the autocomplete off option..

 


form forums I came to know that struts 1.1 does not support overriding
of prepareOtherAttributes method();

 


I would be grateful if I get solution of   how to implement this in all
browsers using struts 1.1.

 


Regards,

Jyotsna.T,



-
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Some parameters from Struts2 to Struts1

[Laurie Harper]

Michał Letyński wrote:

Hi.
I have actions in struts1 and struts2 in one application. Those struts1 
actions will be re-writed in near future to struts2. But i need one 
thing for now. In struts2 (Test.action ) i have some parameters -> 
collection of id's which  i want to transmit to struts1 (Test2.action). 
I cant do a simple forward and i cant do a redirect (my parameters will 
dissappear). A "dirty" workaround for it is to put those parameters to 
the session. Any other ideas ?


Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FileUploadInterceptor problem

[Laurie Harper]

Please post questions about using Struts to the Struts Users list only. 
The Struts Dev list is for discussing the development and enhancement of 
Struts itself.


http://struts.apache.org/mail.html

L.

Michał Letyński wrote:

Hi.
I want to set a maximumSize parameter to FileUploadInterceptor.
In the example, code looks like this:


   12345


FileUploadInterceptor is in the default-stack. My struts.xml config:


   
   
   


How to set the param to the fileupload interceptor ? I tried to 
overwrite this itrerceptor:


class="org.apache.struts2.interceptor.FileUploadInterceptor">

   12345


But didnt work.
I tried to inject this param to default-stack:


   1234


And tried to re-define default-stack to my-stack without fileupload 
inteceptor - other problem occurs with servletConfig interceptor.

Any ideas ?




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to get ActionForm

[Laurie Harper]

Start by asking on the appropriate mailing list ;-) Questions like this 
belong on the users list, not the dev list. Please re-post your question 
there.


L.

Radha Krishna wrote:

Hi,
   
  I want to use the instance of ActionForm associated with current Action in Tag libraries(doEndTag() method). How could i do this.
   
  Thanks in advance


 
-

 Get your own web address.
 Have a HUGE year through Yahoo! Small Business.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: extending AuthorizeAction command in the composable request processor chain

[Laurie Harper]

This is a question for the users list. The dev list is for the 
discussion of developing Struts itself. Please re-post to the users list.


L.

[EMAIL PROTECTED] wrote:
Hello Everyone, 


I've been working on a web application here and I've come up with a situation 
where I feel that extending the AuthorizeAction command class would be a 
quality solution to a challenge I am facing. When I complete this I would be 
willing to contribute this back for others to use.  Here is some necessary 
background on what I am trying to do. Sorry for the length on this:

The application I am working on has complex requirements for role-based authorization checks. When the check fails and the user is not authorized, we do not want to just throw an exception or report an error.  We want to direct the user to a page with instructions on how they can become authorized. Many of the actions will have different requirements, and therefore different checks and different pages with different instructions.  

I came up with what I thought was an elegant and cheerfully easy way to do this, but it has not been so easy as I thought. In the struts-config.xml file I define the action, including its roles, and I include a forward for where the instructions are located for users who fail the authorization checks. Here is an example of one of these actions: 

type="mypkg.CreateOrderAction"

roles="createOrders">
 path="/help/ordersHowTo.do"

 redirect="true"/>


I then wrote a class to replace the default AuthorizeAction class which is part of struts. It contains the complex logic which checks to see if the user has the createOrders role or not. If they do, it would return false to allow the chain to continue. If not, it would retrieve the ForwardConfig for "unauthorized", add it to the context, and then return  true to break what I was hoping was the "process-action" sub-chain, and then the "process-view" chain which executes next would retrieve the ForwardConfig from the context and then send the user there. Unfortunately this does not work the way I was anticipating :-( 

What happens is that the chain stops completely at that point. This is where I get into trouble and I am hoping someone can point me in the right direction. Here is what the default servlet processing chain looks like for me: 




  
  

  

  



Is there a way that I can terminate the "process-action" chain early but still have it execute the "process-view" chain after? I will greatly appreciate any help or suggestions that you can offer. 

Best Regards, 
Aaron Titus



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: BUG - Struts ui components inside mess the layout.

[Laurie Harper]

Firstly, this is really a question for the users list. Please follow up 
there if you have further questions. That said:


Felipe Rodrigues wrote:

Hi everyone,

I'm using a  to organize the layout of my form. I'd like to get all
components in one line, so, I'm using this code:

  
some text
other text



  


But when rendering the page, struts put each component under the other. I
checked out the generated code and found some  tags lost in middle of my
 tags. These  tags was added by struts.

Is that a real bug? Any idea?


No, it's not a bug. It sounds like you're using the 'xhtml' theme, which 
is designed to automatically lay your forms out using table. For your 
use case, you'll need to use the 'simple' theme instead.


Be aware that you'll need to take care of showing field labels, error 
messages, etc. yourself when using the 'simple' theme.


See the documentation for more:

http://struts.apache.org/2.x/docs/themes-and-templates.html
http://struts.apache.org/2.x/docs/xhtml-theme.html
http://struts.apache.org/2.x/docs/simple-theme.html

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: weblogic 8.1 sp3 with struts2

[Laurie Harper]

Please post questions like this to the users@ list. dev@ is for 
discussion of the development of Struts. Questions about using it belong 
on [EMAIL PROTECTED]


Thanks,

L.

hfaouaz wrote:

I am getting a NPE after the action return a success.  My struts.xml has the 
location but org.apache.struts2.dispatcher.ServletDispatcherResult is saying 
that the location is null and I get a result 'null' not found on the screen.

Weblogic 8.1 sp3
Jrocket 1.4
struts2 j4

any ideas any one?
thanks
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=72243&messageID=134732#134732



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Migrating from 2.0.1 to 2.0.6

[Laurie Harper]

This is really a question for the user list. Please follow-up there if 
you have additional questions. That said, you will find the information 
you need in the release notes. Unfortunately there isn't a single, 
consolidated source for 2.0.1 to 2.0.6, so you'll need to look at the 
release notes for each of the builds in the series:


http://struts.apache.org/2.x/docs/release-notes-202.html
http://struts.apache.org/2.x/docs/release-notes-203.html
http://struts.apache.org/2.x/docs/release-notes-204.html
http://struts.apache.org/2.x/docs/release-notes-205.html
http://struts.apache.org/2.x/docs/release-notes-206.html

L.

Shekhar Yadav wrote:

All,

Is there a document somewhere which tells how to migrate from 2.0.1
version to 2.0.6. I tried migrating and I am running into issues with
tiles.xml and dojo. If there is a consolidated list somewhere to look at
it would be helpful. Else, I guess I will have to go with trial and
error.

Thanks,

Shekhar



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Blank Struts page after submit

[Laurie Harper]

Please post questions like this to the users list rather than the devel 
list; this list is for discussion of the development of Struts itself. 
Also, you should include your relevant config (form bean definitions and 
action mappings, etc.) and, if possible, simplify the code down as much 
as possible so it's easier for people to concentrate on the relevant bits.


L.

simistef wrote:

Hi !

I am learning to work with struts, after i click on submit button (in a
form) i get a blank page. This thing is annoying me because i can't find the
solution for a week !

The page has 2 hmtl list option. The first list loads info about a company
compartiments, and after hitting "Refresh Employees", the second list should
shouw data about all the employees from the selected department.

What is happening ? After hitting "Refresh Employees" i get a blank
selectAngajat.do page. If i go Back and Refresh(F5) the second list option
shows all the employees from that department.

Does anyone have any idea about this ? I posted some code down:

PersonalBody.jsp
[code]
<%@ page import="databeans.*"%> 
<%@ page import="java.sql.Connection"%>

scope="session"/> 




Selectati un Compartiment:


<%
Connection conn=Utilitati.getConexiune();
java.util.ArrayList listaCompartimente=
ObiectPersistent.getObjects(Compartimente.class,conn,null); 
conn.close();
for(int i=0;i%>


<%=((Compartimente)listaCompartimente.get(i)).getNumecompart()%> 


<%}%> <%-- s-a inchis for-ul--%>






 

Selectati Angajatul: 



<% Connection conn=Utilitati.getConexiune();
if (ss_PersSelected.getCompartid() != null) //exista un compartiment
selectat
{ java.util.ArrayList listaAngajati = 
ObiectPersistent.getObjects(Personal.class,conn,

" where compartid='"+ss_PersSelected.getCompartid()+"' ");
conn.close();
for(int i=0;i

<%=((Personal)listaAngajati.get(i)).getNumepren()%>

<%}}%> <%-- inchidem FOR si IF --%>




 
 





<%if (request.getSession().getAttribute("ss_DatePers") != null){%> 
 <%} 
else if (ss_PersSelected.getCompartid() != null){%> 

 
 


<%}%>
[/code]

struts-config.xml
[code]





 








[/code]

SelectAngajatAction.class
[code]
package formactions;

import databeans.CompartPersSelectedBean;

import databeans.ObiectPersistent;
import databeans.Personal;
import databeans.Utilitati;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;

public class SelectAngajatAction extends Action {

public ActionForward perform(ActionMapping mapping, ActionForm form, 
 HttpServletRequest request, 
 HttpServletResponse response) throws
IOException, 
 
ServletException {

CompartPersSelectedBean formBean = (CompartPersSelectedBean)form;
java.sql.Connection conn = null;

if (formBean.getMarcaselectata() != null && 
formBean.getMarcaselectata().intValue() != -1)

try { // incarc in sesiune obiectul Personal corespunzator
marcii selectate de utilizator 
conn = Utilitati.getConexiune();
Personal objPersCurent = 
(Personal)ObiectPersistent.getObjects(Personal.class,
conn, 
  "where marca=" + 
 
formBean.getMarcaselectata().toString()).get(0);

// ATENTIE! Identificatorul atributului trebuie sl fie cel
definit in Struts-Contig.xml 
request.getSession().setAttribute("ss_DatePers", 
  objPersCurent);



conn.close();

} catch (Exception e) {
e.printStackTrace();
if (conn != null)
try {
conn.close();
} catch (Exception err) {
err.printStackTrace();
}
return mapping.findForward("eroareBD");
}
else // daca marca e null elimin eventualul atribut ss_DatePers
anterior
request.getSession().removeAttribute("ss_DatePers");

return mapping.findForward("success");
}
}
[/code]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: per-method validations for annotations

[Laurie Harper]

David Rupp wrote:

Hi, all.

I've submitted a patch to the XWork project (issue XW-470) that enables 
per-method validations when using annotations. This is, IMO, an 
improvement over the current behavior, with which all validations are 
attached to the class, and *all* fire when *any* method is executed. 
Since validation annotations, by definition, *must* be defined on a 
specific method, it seems more reasonable to expect that the validations 
defined on a given method would fire when - and only when - that method 
is executed.


I have a specific need for this behavior on my current project, but I'd 
rather not be in the position of maintaining a forked version of XWork 
just for it. I'd love it if some of the folks from this group could take 
a look at my patch (included on the issue) and let me know how it can be 
improved, assuming I'm not the only one who would like to see this 
behavior implemented.


+1, since we've already had at least one user expecting it to work like 
this and it would certainly make the framework more flexible. I haven't 
looked at the patch but I'd like to see this functionality added, in 
some form.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: s2 Code Behind bug?

[Laurie Harper]

Yup, that gets it working. I mis-spoke before; an empty public class 
Dummy{} in the package isn't enough, but an empty public class Dummy 
extends ActionSupport {} (or a POJO class named xxxAction) is.


So: by design, or oversight? :-)

L.

Don Brown wrote:
I'm assuming you were calling the page with 
http://localhost/myapp/foo/bar.action?  If so, I wonder if the plugin 
only works when there is at least one action class in a package.  Try to 
create a different action like com.foo.action.foo.BazAction in that same 
package, and see if the plugin then works.


Don

Laurie Harper wrote:
I'm trying to get a project running with the Zero Config and Code 
Behind Plugin features of S2 and I'm seeing something which looks like 
a bug. I thought I'd raise it here before posting it to JIRA and/or 
trying to dig through the plugin code to track it down, in case this 
is 'by design' or something.


The problem is when I create a page for which there is no action, and 
the package the action would be in doesn't exist. E.g.:


- actionPackages set to com.foo.action
- page located at /foo/bar.jsp

When I request the page, code behind reports "Trying to locate unknown 
action template with extension .jsp in directory /" -- it should, of 
course, be looking in /foo. The request therefore fails.


However, if I create the package com.foo.action.foo (and put a dummy 
class in there so the package will exist at runtime), everything works 
as it should.


That seems wrong to me... am I missing anything? And if not, where 
should I start looking to debug and fix it?


Cheers,

L.


-
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]

s2 Code Behind bug?

[Laurie Harper]

I'm trying to get a project running with the Zero Config and Code Behind 
Plugin features of S2 and I'm seeing something which looks like a bug. I 
thought I'd raise it here before posting it to JIRA and/or trying to dig 
through the plugin code to track it down, in case this is 'by design' or 
something.


The problem is when I create a page for which there is no action, and 
the package the action would be in doesn't exist. E.g.:


- actionPackages set to com.foo.action
- page located at /foo/bar.jsp

When I request the page, code behind reports "Trying to locate unknown 
action template with extension .jsp in directory /" -- it should, of 
course, be looking in /foo. The request therefore fails.


However, if I create the package com.foo.action.foo (and put a dummy 
class in there so the package will exist at runtime), everything works 
as it should.


That seems wrong to me... am I missing anything? And if not, where 
should I start looking to debug and fix it?


Cheers,

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cwiki karma

[Laurie Harper]

Thanks :)

Don Brown wrote:

Done.

Laurie Harper wrote:
Could someone grant me karma for the S2 wiki (username laurieh)? I 
want to fix the broken snippet macros in the tag ref as I come across 
them so I can actually read the documentation ;-)


Thanks,

L.


-
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]

cwiki karma

[Laurie Harper]

Could someone grant me karma for the S2 wiki (username laurieh)? I want 
to fix the broken snippet macros in the tag ref as I come across them so 
I can actually read the documentation ;-)


Thanks,

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Tiles PMC Chair

[Laurie Harper]

David H. DeWolf wrote:

[x] Greg Reddin (greddin)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Tiles TLP

[Laurie Harper]

David H. DeWolf wrote:

[x] +1  = Yes, let's ask the board to establish the Tiles TLP



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: change the presentation of struts validator framework errors on jsp page?

[Laurie Harper]

This is really a discussion for the Struts Users list, rather than the 
dev list; please follow up with any further questions there.


However, in brief, there is currently no support for displaying 
client-side validation errors as in-line HTML like you show server-side 
validation errors. Simply disabling client-side validation (by not using 
the html:javascript tag in your forms) should allow all validation to 
occur server-side, and all validation errors (from automatic validation 
and from and manual validation) to be displayed the same way.


L.

Sarry wrote:


I don't know how to implement it, cosider me a new bee here.

Lets take the scenario like I have a client side validation enabled for a
particlar field and it is done in java script so if some validation rule
fails it will pop an alert message, we have some business errors which are
shown on page itself with bold text or something.

we would like to have an uniform mechanism to get these alert messages to be
shown on the page itself.
this article is good but I m not sure if it is possible to validate on the
client side thru java script and pass the error message in Action error to
display on the JSP page thru HTML error tag.

I have one more approach if I disable this validation on the client side and
let the server validate it.howver i have no experience how to validate on
the server side and get the error message in the object?


Regards,

Sarry

Dave Newton-3 wrote:

User list.


I would like to know if there is any way to change the presentation of
struts validators framework errors.

http://struts.apache.org/1.2.x/userGuide/struts-html.html#errors

Dave

-
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: [VOTE] Promote Struts 1.3.5 to General Availability

[Laurie Harper]

Wendy Smoak wrote:

[X ]  +1Yes, Struts 1.3.5 should be promoted to GA quality.
[  ]  +/- 0
[  ]  -1 No, let it remain Beta quality



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)

[Laurie Harper]

The var-args log message construction is definitely a nice bit of 
syntactic sugar, but removing the guard seems unwise; sure, there's no 
string concatenation in the call to log.debug, but there's an implicit 
Object[] instantiation, which isn't much better. There's a reason every 
major logging API includes isLoggable/isDebugEnabled/whatever guard 
methods...


L.

Don Brown wrote:

I think a couple extra classes is worth switching from this:

public Order createOrder(User user, Product product, int quantity) {
   if ( log.isLoggable(Level.FINE) ) {
   log.fine("Creating new order for user: " + user.username() + 
   " product: " + product.name()+ " quantity: " + 
quantity);

   }
   return new Order(user, product, quantity);
}

to this:

public Order createOrder(User user, Product product, int quantity) {
   log.debug("Creating new order for user: #0 product: #1 quantity: #2", 
user.username(), product.name(), quantity);

   return new Order(user, product, quantity);
}


Considering how often we log things, I think the cleanup is huge and a 
few classes are definitely worth the price.


Don

Bob Lee wrote:

On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:


Well, for one, we only really need one logging instance for the whole
library.  Second, and admittedly this is subjective, the
java.util.logging API is a horribly designed, obtuse API.  I'd rather
see us write a small, clean API along the lines of Seam's logging class
that utilizes varargs to reduce the need for isDebugEnabled().



I agree that j.u.logging is a PoS, but it's ubiquitous, and for our
purposes, it workds fine. We may only need one logger for the whole
framework, but it's just as easy to create a logger per class, and you 
can
still configure them all at once. I'd rather fix j.u.logging than 
build yet

another API.

Bob




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s1] Commons-Lang

[Laurie Harper]

Don Brown wrote:

In this case, yes, we need to log, however, as a library, the only
messages the user will care about are those that are from the library
as a whole.  If the user needs to filter at a package level a
library's log messages, that library has problems :)


Agreed, *up to* the point where you need to enable debug logging. At 
that point, the logging verbosity pretty much always makes it preferable 
to be able to filter by specific packages/classes. And yes, I realize I 
can filter by post-processing my logs if there's enough information 
written to the log file but... ;-)


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Struts 1.3.5 Quality - RESULT

[Laurie Harper]

Wendy Smoak wrote:

On 8/1/06, Ted Husted <[EMAIL PROTECTED]> wrote:

My copy of mvn doesn't seem to think that download sources is an 
option :(


You try it with -U to see if you've got the latest IDEA plugin.  I
forget when that was added.  If not, depending on how much time you
have to spend on this, my next step would be to build
maven-idea-plugin from source.  Or I'd script a bunch of 'wget ...'
statements to grab what I needed.


Heh, or just munge the command slightly... it should be

  mvn idea:idea -DdownloadSources=true -DdownloadJavadocs=true -Papps

i.e. with '-Ddownload...' not just '-download...'. Works for me :-)

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OGNL - Getter and setter types must match

[Laurie Harper]

The restriction comes from the Java relection API semantics, not OGNL. A 
property can only have one type, so it makes sense that the getter and 
setter for a JavaBean property must agree on that type. Changing this 
would break compatibility with the JavaBean specification, at the least...


L.

Ian Roughley wrote:
I'd be up for lifting the restriction, but I also don't have access to 
the code.


/Ian



Bob Lee wrote:

Thanks for the explanation. What a silly restriction. Anybody up for
removing it? I don't have access to the OGNL source.

Bob

On 6/27/06, Ian Roughley <[EMAIL PROTECTED]> wrote:


I've come across this also, and the way I explained it was that it had
something to do with matching getters and setters to be well formed java
beans.  Although I never took the time to look into it further.

/Ian



Bob Lee wrote:
> I've run into this problem with OGNL where I want it to invoke a
> setter, but
> if there's a getter method with the same property name but a different
> type,
> OGNL will just fail silently. Why does it even care about the getter?
> Anyone
> have an idea of what's going on here?
>
> I'm working against the OGNL version that went out w/ WW 2.2.2.
>
> Bob
>

-
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: SAF1 Checkstyle

[Laurie Harper]

Frank W. Zammetti wrote:

Ted Husted wrote:

You might at least want to start those discussions about the
checkstyle settings, so that we can develop a strategy about how they
would be fixed the next time there is a window of opportunity.


Fair enough...

I saw two issues that seem to account for a large number of the 
complaints...


* The issue "Variable  must be private and have accessor methods.". 
 This is the VisibilityModifierCheck check.  I don't think directly 
addressing it, i.e., following the suggestion it gives, is the right 
answer... I can't imagine it wouldn't break things, either in the SAF 
codebase itself or in users' application code.


Fortunately, there appears to be a setting in Checkstyle to deal with this:

http://checkstyle.sourceforge.net/config_design.html#VisibilityModifier

Or we could remove this check entirely.  I'd vote for just setting 
protectedAllowed to true though.


Since this is a change to the checkstyle rules, not a change to the 
codebase, I don't think it needs to wait for a release/GA/whatever. 
Might as well just get it done now...


Looking at core alone, that would probably get rid of half of the 
remaining issues.  This is the only proposed rule change I have at this 
point.


* The issue "Expected @throws tag for ".  This is coming up a lot 
because there are runtime exceptions thrown in methods that are not 
declared (which is of course valid, but doesn't follow the style rules). 
 I would suggestion simply declaring them... I don't *think* that has 
any side-effects... anyone think there is?


Declaring runtime exceptions in the throws clause of a method signature 
has no impact on the signature, so it should be safe. However, it's 
generally considered poor style (on what basis I don't know, doesn't 
seem like a problem to me, but...). If there's a checkstyle rule change 
that could be used to take care of this then, again, there'd be no need 
to wait. If it really does need code changes, it'd be worth holding off 
but opening a JIRA issue so we don't forget to come back later.


L.




When I did a a time study in February, curing the the current errors
with the current settings would take at least 40 hard hours. We need
to find a way to do the work faster, or get more people to work on it.


Agreed, and your estimate may even be too optimistic given that first 
bullet above, if the rule change wasn't implemented.  I frankly don't 
see another way to deal with that particular complaint.



(We probably should have made this a Google Summer of Code project.)


Hehe, yeah :)


There is also the issue of how we want to handle the exception issues.
We will be addressing exception handling in SAF 2, so it's a pertinent
question.


I certainly don't disagree that some exception handling updates should 
be looked at, but I'm not sure that's pertinent in the context of 
Checkstyle complaints... the exception bullet above I don't think should 
be expanded to modifying how exceptions are handled now, it's just 
getting rid of the complaints, which I think is as simple as declaring 
the exceptions.



We might also consider fixing some of the errors at a time, for
example maybe just the exception handlers. That could have less of an
impact that trying to cure all six thousand at once.


Same point as the above paragraph... I think we're talking about two 
different things really.


Although, if you wanted to tackle just one category of complaint at a 
time, that would be fine... I was thinking of a package at a time, but 
the work breakdown can certainly be done any of a number of ways.


Ultimately though, that one rule change above would cut down a pretty 
substantial number of complaints, and in this case I don't think 
changing the rules is a cop-out.  So, I'd like to see a consensus 
reached on that alone, everything else could be back-burnered as far as 
I'm concerned.



-Ted.


Frank



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept and Graduate WebWork 2 Podling to Struts

[Laurie Harper]

+0 (non-binding) with the same caveat.

L.

Greg Reddin wrote:
+0.  I'd say +1, but it looks like it will be a bit before I have a 
chance to get more involved.


Greg

On Apr 28, 2006, at 1:19 PM, Don Brown wrote:

I call a vote that the Struts PMC accept the WebWork 2 podling as 
having met the incubation requirements and thereby be accepted by the 
Apache Struts project as Struts Action 2.


Status: http://incubator.apache.org/projects/webwork2.html

[ ] +1 Let's bring it in, and I'm committed to the project
[ ] +0 Let's bring it in, but I won't be involved
[ ] -0 I'd rather not, but I'm not involved, and here's why...
[ ] -1 Let's not, and here's why...

We welcome votes from all community members, however, only the votes
of Struts PMC members are binding.

If this vote passes, the Incubator will need to vote for the 
graduation to be complete.


Here is my +1

Don

-
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: [action2] Switching to Dojo widgets

[Laurie Harper]

Martin Cooper wrote:

When you build (or download) a specific profile, the dojo.js file contains
only what is defined for that profile. However, everything else is still
available. Any code that is "dojo.require"d that is not part of the profile
will be dynamically fetched by Dojo when that 'require' is evaled. That's
why you need the source directory. The only situation in which this is not
true is if you use the kitchen sink profile, since by definition it includes
everything.


Just to avoid future confusion: that's not quite true. Kitchen sink 
still doesn't include the code for the individual widgets, on the 
assumption that very few apps/pages would need many of them at once, so 
even with Kitchen Sink you still want the src/ folder around.


Additionally, there are other files you need under src/, such as HTML 
widget templates, CSS and image files.



The trade-off is between having a larger download on startup versus having
multiple requests for individual pieces. Right now, I think it's fine to
have a minimal profile and then have each component fetch any additional
pieces it needs, which is what Don has done.


+1, it's really easy to create a custom profile with Dojo, and most 
browsers will cache the dynamically loaded Javascript anyway so, as with 
regularly included static resources, the download hit is one-time. If 
there's anything (tooltips?) that's likely to be used by every page, it 
may still be worth baking it into the profile, but otherwise, keep it 
minimal.


L.


--
Martin Cooper


If you like I can assist, but I won't have time till late next week at

the earliest.

/Ian


Don Brown wrote:


Ian, what about using the minimal profile, but each component that
needs something more can do a dojo.require() to pull it in?  A user's
application, that knows they need more, can overwrite head.ftl to
change the profile.  This is the change I plan to do today.

Don

Ian Roughley wrote:


Martin - which profile do you suggest?  I had a quick look over the
profiles awhile back, and the only ones from the kitchen sick that I
thought could be removed were "flash" and "storage" - especially with
the incorporation of more widgets.

The other option would be to have different profiles to download
which are dependent on which widgets you are using, but this seems
like it would be much more trouble as well as more custom
configuration (which we have been trying to avoid).  What are your
thoughts?

My other plan (to which I owe Jason an apology as I ran out of time)
was to upgrade to 0.2.2 and use the compressed version rather than
the exploded version.

BTW - the dojo editor is already incorporated as an ajax themed
textarea, however as for 0.2.1 it is still seems a little buggy.

/Ian



Martin Cooper wrote:


On 4/12/06, Don Brown <[EMAIL PROTECTED]> wrote:



I'm starting to look into replacing the LGPL Javascript components
with
ones provided by Dojo, a toolkit we are already
using.  Dojo already has the following widgets:

 - date picker -


http://archive.dojotoolkit.org/nightly/tests/widget/test_DatePicker.html

 - tooltip -
http://archive.dojotoolkit.org/nightly/tests/widget/test_Tooltip.html
 - rich text editor -
http://archive.dojotoolkit.org/nightly/tests/widget/test_Editor.html

My question is how should we handle the Dojo imports?  Currently
Dojo is
only imported in the header of the ajax theme.
 I propose we import dojo.js in the header of the simple theme
(which is
imported by the other themes), leaving each
component to do the dojo.require() call to ensure their widget is
available.




This makes sense to me.

However, I think we should change the current strategy on the Dojo
profile
that's bundled by default. It looks like the kitchen sink profile is
what's
bundled today. It would make more sense, IMHO, to bundle the minimal
profile
(or at least somewhat more minimal than kitchen sink) by default,
and to
provide the kitchen sink as an option and / or provide instructions
on how
to construct a custom profile (which is really easy). I'm certainly
willing
to help out here.

--
Martin Cooper


Don



-
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]




-
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]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [WebWork2] TODO

[Laurie Harper]

Joe Germuska wrote:

At 7:39 AM -0500 3/27/06, Ted Husted wrote:

Walter Zorns tooltip library for all UI Tags
* Is there a Dojo equivalent?


I'm pretty sure there is not.


I haven't looked at the Walter Zorn tooltips, but Dojo does have a 
tooltip widget:


http://dojotoolkit.org/~dylan/dojo/tests/widget/test_Tooltip.html

Is that what would be needed?

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANNOUNCE] Struts Action 1.3.1 Test Build available

[Laurie Harper]

Wendy Smoak wrote:

On 3/11/06, Laurie Harper <[EMAIL PROTECTED]> wrote:

Wendy Smoak wrote:

As a reminder, Struts Action Library 1.3_00, which contains the
version 1.3.0 test builds of all Struts Action sub-projects, can be
downloaded from this location:
   http://cvs.apache.org/dist/struts/action-lib/

Is that useful in this context, given that it contains 1.3.0? Shouldn't
a 1.3_01 be added?


We aren't planning to do another Library distribution until all of the
sub-projects make it to General Availability.


Ah, OK, that makes sense.


I can leave that part out of the announcement to user@ if it's too
confusing, but struts-action-1.3.1.jar alone isn't very useful-- if
you're building an app you probably also want taglib, el, tiles... and
the dependencies, which I neglected to mention are also in the Library
distribution.


Either that, or clarify that Action 1.3.1 is not included in Library 
1.3_00 and needs to be added. I'm less worried about how confused users 
will be than how confused *we* will when they start asking questions / 
reporting problems if they didn't deploy things right ;-)


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANNOUNCE] Struts Action 1.3.1 Test Build available

[Laurie Harper]

Wendy Smoak wrote:

As a reminder, Struts Action Library 1.3_00, which contains the
version 1.3.0 test builds of all Struts Action sub-projects, can be
downloaded from this location:
   http://cvs.apache.org/dist/struts/action-lib/


Is that useful in this context, given that it contains 1.3.0? Shouldn't 
a 1.3_01 be added?


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts Action Friends 1.3.0 MVC

[Laurie Harper]

Ted Husted wrote:

I'd like to nominate Wendy Smoak as the Most Valuable Committer in
making the release of the new 1.3.0 builds possible.

Along with James Mitchell, Wendy did the thankless scutwork of taking
the Maven builds from prototype to production. Without her tireless
efforts, we'd still be kilometers away from the 1.3.0 milestones. A
lot of us worked on code, and a lot of us worked on documentation, but
without infrastructure, nothing else matters.

Here's my +1.

-Ted.


+1, absolutely!

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan

[Laurie Harper]

Another way of looking at it is that such a tag would be capturing the 
same information as the Maven POM... The main value of a tag is to allow 
someone to check out all the code for a given release at once. Checking 
out just action and letting Maven pull the release jars for the other 
sub-projects gets you there anyway IMHO.


L.

Ted Husted wrote:

Did we tag current for the Struts-Shale_1.0.0 and
Struts-Scripting_1.0.0 releases?

For the Action Library, right now, I'm only planning to post the JARs
(including external dependencies), which are all self-tagged for the
appropriate release.

Conceptually, I'm thinking of the Library as the set of Struts GA
releases that are dependant on Action and work with a given Action GA.
(So, technically, right now, that's a null set, since we have no GA
releases, but we should at least prime the pump. )

In the future, if we wanted to a tag for that set, we might have to
use a "working copy" tag, since it probably would not be a tag against
the HEAD, but against some GA tag for each of the different
subprojects. It would be a mix of revisions.

* http://svnbook.red-bean.com/en/1.1/ch04s06.html#svn-ch-4-sect-6.2

Though, the Action Library release manager would not need to obtain
the set of source file as a matter of course. No more than we need to
obtain the source for a Commons JAR. The release manager for an Action
Library would only need to test the JARs already decreed GA, the same
as we do for Commons JARs.

My question would be whether we are going to expect an Action Library
release manager to go through the work of making a complex tag?

If someone wants to check-out the Struts source for each of the JARs
and create the tag, that's great, and it would be a good idea to have
a cannonical place to put such a tag. But being a release manager is
hard enough without making work. If someone needs the set, the set is
obtainable. If we need it, then we can create it when we need it, and
save it somewhere so someone doesn't need to create it again. But
creating it up front seems like busy-work.

-Ted.

On 2/17/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:

On 2/17/06, James Mitchell <[EMAIL PROTECTED]> wrote:


Did we tag every subproject?  Including 'current'?  Maybe I just
missed it.

I didn't see a tag for current... but there is no trunk/branches/tags
directory structure there, either.

It seems to me that we need a tag for (something like)
ACTION-LIB_1.3_00, so you can grab all the "right" versions of the
sub-projects that go with a particular library distribution.  These
are the ones we've tested to make sure they work together.  I'm just
not sure where to put it.  What about in struts/action/tags or just
struts/tags ?  Current doesn't seem like the right place, no one would
go looking in "current" for an old release.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan

[Laurie Harper]

Laurie Harper wrote:

Ted Husted wrote:

On 2/16/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
If we think this is serious enough to warrant a 1.2.9 release, then 
it makes
little sense to me to tag 1.3.0 without it. Otherwise, all we're 
saying is

"hurrah, we tagged the tree, but oh, you probably don't want to use this
because there's a serious problem we know about that we didn't feel like
taking the extra time to fix".


All I'm saying is that I have no "extra" time. If someone else does,
then please step up and lend a hand.


That's part of my reason for +1'ing a 1.3.0 release, even if it's never 
promoted (as a whole) from test release; Ted's put a ton of work into 
getting to this point. If a 1.3.0 release happens now, it'll presumably 
take less time and effort to incrementally address remaining issues and 
release updates of just the action sub-project, compared to postponing 
the 1.3.0 release and having to repeat much of the testing and prep work 
that's just been done.


Oops. Ted and others have put... Sorry, didn't mean to allocate the 
blame^H^H^H^H^H^H credit to just Ted.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan

[Laurie Harper]

Ted Husted wrote:

On 2/16/06, Martin Cooper <[EMAIL PROTECTED]> wrote:

If we think this is serious enough to warrant a 1.2.9 release, then it makes
little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is
"hurrah, we tagged the tree, but oh, you probably don't want to use this
because there's a serious problem we know about that we didn't feel like
taking the extra time to fix".


All I'm saying is that I have no "extra" time. If someone else does,
then please step up and lend a hand.


That's part of my reason for +1'ing a 1.3.0 release, even if it's never 
promoted (as a whole) from test release; Ted's put a ton of work into 
getting to this point. If a 1.3.0 release happens now, it'll presumably 
take less time and effort to incrementally address remaining issues and 
release updates of just the action sub-project, compared to postponing 
the 1.3.0 release and having to repeat much of the testing and prep work 
that's just been done.


Just my 2 cents...

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan

[Laurie Harper]

Ted Husted wrote:

If some people feel these patches are a problem, then we can always
keep Action 1.3.0 as a test-build, until someone has time to apply
them and roll an Action 1.3.1 (note that the other six subprojects
would *not* have to tagged and rolled again, only the one we change).

The important thing, I think, is to get past the point having to
release everything all at once. Then we can address any other issues
in an agile, release-often, way. Otherwise, it will always be
something, and a week will turn into a month, which turns into another
quarter.


+1 to this action plan. I'm in the camp of considering the two security 
bugs a requirement for a GA level release, but getting the 'seven 
dwarfs' out the door would at least clear some room in the workshop ;-)


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[OT] ASF legal

[Laurie Harper]

What's the best way of getting hold of an ASF legal maven? I've been 
doing a bunch of work with Dojo recently and one fly in the ointment is 
that they require filing a CLA before they'll accept patches, even for 
minor bug fixes.


The reason they do that is they want to be absolutely safe, which I 
understand. But since it doesn't work that way round here, I thought I'd 
see if I could get an IAAL (as opposed to an IANAL :-) opinion on why 
it's not needed.


This could help the Dojo project out quite a bit, since they often 
receive patches from casual users who probably aren't going to go to the 
trouble of filing a CLA. They'd like to drop the requirement, and a 
legal opinion explaining why that would be OK would be a great help.


Is there a [EMAIL PROTECTED] or something I can post this query to?

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Help adding Struts to AJAX impl

[Laurie Harper]

Sounds like it'd be a lot easier to just fire the first request with a 
handler function that fires the next request, and so on, using 
onreadystatechange.


L.

Frank W. Zammetti wrote:
No Wendy, you are correct in your explanation :)  I see Ajax in Action 
is serving you well :)


I wouldn't expect it to be the best answer though because that parameter 
blocks *all* Javascript, not just further XMLHttpRequest's.


What you will probably want to do Michael is build up a queue on the 
client and write some code to ensure the order the handlers fire.  This 
could be pretty tricky to say the least.


Take a look at the RequestSender tag in AjaxTags in Java Web Parts... 
AjaxTags builds up such a queue so that multiple requests can fire 
simultaneously without stepping on each other.  I suspect you would be 
able to extend this to ensure firing order.  Off the top of my head, I 
would think you would need to set up a timer, and when the responses 
come back, instead of processing them on the spot in the callback, 
instead set a flag in the call structure that says "yes, this request 
completed, but don't process it until the previous one completes"... 
fire the timer every half a second or something like that to examine all 
the call structures in the queue and fire them as appropriate.


Probably not a trivial exercise, but should be doable.

Frank


Wendy Smoak wrote:

On 2/1/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:


Hi, Ajax gurus, I have an OT question: how to ensure the proper order
of several XHRs? I found how to create several XHRs simultaneously,
but I have a requirement: to wait for the first request to return
before firing the second,


(Hardly an expert but...) the third parameter of
XMLHttpRequest.open(...) is a flag that says whether the request
should be asynchronous.  It's usually true.  Set it to false and I
think it will block until the response is received.  Frank will now
correct me if I'm wrong. :)

And lets move to the user list if this gets any further off topic, 
shall we?


--
Wendy

-
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: [VOTE] Accept WebWork 2 Merger Incubator Proposal

[Laurie Harper]

+1 non-binding

Don Brown wrote:

http://wiki.apache.org/struts/WebWork2Incubator

= PROJECT PROPOSAL =

WebWork 2:  A Java web application development framework

A proposal to merge the WebWork 2 community and codebase into the Apache 
Struts project. The new codebase is slated to become Struts Action 2.


= RATIONALE =

The members of the Apache Struts project and the members of the 
OpenSymphony WebWork 2 project would like to work together on a 
next-generation web application framework utilizing an action/request 
architecture. WebWork was initially created by Rickard Oberg to improve 
on the ideas and functionality of the Jakarta Struts framework. (Now 
known as the Apache Struts Action framework.) Since then, the WebWork 
community has continued to extend and refine the framework's 
capabilities through a long series of releases, the latest of which, 
2.2, brings advanced Ajax, templating, and Java 5 capabilities to its 
solid WebWork 2 foundation.  While, to date, the WebWork and Struts 
Action codebases have overlapped, recent movements to bring 
consolidation to the web framework landscape have inspired both 
communities to work together. Apache Struts has recently reorganized our 
codebase into multiple subprojects, two of which, Shale and Action, 
represent two separate but equal web frameworks. Struts Shale serves the 
nascent JSF community, while Struts Action serves the established JSP 
community. The WebWork 2 code would be brought into the Action 
subproject as the 2.x branch.  The WebWork 2 developers are excited by 
the prospect of joining the ASF and collaborating to solve our common 
need for a solid, action-based MVC2 web framework. 
= CRITERIA =


== Meritocracy: ==

The WebWork 2 community is a healthy meritocracy with multiple 
developers who do not share a common employer. The creator of the 
project has already "passed the torch" to another generation of 
developers, who earn commit privileges through their individual 
contributions.


== Community: ==

The WebWork 2 community has a strong following with active mailing lists 
and forums.


https://webwork.dev.java.net/servlets/ProjectMailingListList

== WebWork Developers: ==

The WebWork developers includes individuals who have been with the 
project for a very long time and individuals who have only recently 
earned commit privileges. Contributions come steadily from all segments 
of the community, developer and user alike. Despite being used by many 
well-known corporations, WebWork 2 has not received any direct corporate 
contributions.


http://www.opensymphony.com/webwork/members.action

== Alignment: ==

WebWork and Struts Action are both action-oriented web frameworks, and 
the basic underlying models of the two are similar in many respects. 
Thus both projects strive to serve largely the same community of Java 
web application developers.


== License ==

WebWork 2 is under the OpenSymphony 1.1 license, a modified Apache 
Software License 1.0.


* 2001-2006 http://www.opensymphony.com/webwork/license.action

= AVOIDING THE WARNING SIGNS =

== Orphaned products: ==

WebWork 2 will form the base of Struts Action 2.0 and is under heavy 
active development.


== Inexperience with open source: ==

The WebWork 2 project has been operating as a successful open source 
project for over four years.


== Homogenous developers: ==

The current list of committers includes developers from several 
different companies who are geographically dispersed. The developers are 
experienced with working in a distributed environment, and with 
resolving differences outside the scope of a common employer.


== Reliance on salaried developers: ==

WebWork does not rely on contributions from salaried developers, nor 
have commit privileges been extended based on an individual's employer.


== No ties to other ASF products: ==

The heritage of WebWork yields many close ties with the Apache Struts 
community. Many users have used one framework, then the other, and have 
different projects in the field that use either. The WebWork 2 codebase 
also uses several Jakarta Commons libraries.


== A fascination with the ASF brand: ==

After several years of independence, the WebWork developers are ready to 
work within a larger community and expose the WebWork technology to a 
wider audience. The WebWork community is not seeking the ASF brand but 
seeks to collaborate with like minds in the Apache Struts projects. Both 
sets of developers are trying to solve the same problems in the same 
way, and we feel that we can create a stronger community and codebase 
together, than we can working independantly.


= INITIAL SOURCE =

The initial source comes from the WebWork 2 project, which uses CVS 
hosted at java.net.


* http://opensymphony.com/webwork/cvs.action

= RESOURCES TO BE CREATED =

* None. (Struts Action SVN module and build systems already exist.)

= INITIAL COMMITTERS =

* Jason Carreira (jcarreira at apache.org)
* Don Brown (mrdon at apache.org)

Re: Validation Security Hole?

[Laurie Harper]

Paul Benedict wrote:

Laurie,

Do we have a proprosed solution? I volunteer to write it, whatever we decide 
on, unless a
committer feels it is more appropriate for him/her to write it.


I believe we have several proposed solutions:

- add an action-mapping config option to enable cancel processing, and 
ignore the cancel request parameter if the action mapping isn't 
configured to use it


- add an Action.canceled() method which would be called instead of 
Action.execute() if the cancel parameter is included in the request, and 
make the default implementation return an error response


- add a Cancelable interface which an Action must implement to get 
cancel processing; ignore the cancel param if the interface isn't 
implemented


I've listed those in my personal order of preference ;-) I think an 
additional method on Action with a default implementation is better than 
just a marker interface, but it's still more intrusive than I'd like.


The config-based solution is a) easiest to deal with during an upgrade 
(no need to change any code, existing action implementations that check 
isCancelled will work without re-organizing them, etc.); and b) a clean 
declarative way of specifying the desired behaviour. It also has the 
advantage of working identically regardless of if you're using Action, 
DispatchAction, or whatever.


The disadvantage is that it may be slightly harder to implement in 
Action 1.2.x than in 1.3, but I don't think that's insurmountable if we 
agree it's the right approach.


Oh, and that's ignoring the 'do we need it' / 'does anyone use this' 
type questions. I believe this *is* something that's needed, even if 
it's only used by some people. Removing html:cancel and the associated 
processing doesn't seem to be a viable option, IMHO ;-)


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Validation Security Hole?

[Laurie Harper]

Joe Germuska wrote:

At 11:38 AM -0500 1/23/06, Frank W. Zammetti wrote:

Joe, I think Rick is correct, I too do not see how this will solve the
problem.

Recall that the way it works today, you can bypass validate() being fired
for *any* Action, not just those which are designed to handle a cancel
button.  This is where the problem arises... depending on what is done in
validate() (whether we as architects find it appropriate or not) can 
cause

problems in execute() and beyond, potentially security problems.

Of course, perhaps Rick and I are *both* not seeing it :)


Or it could be me.  But this solution puts burden of activating the 
cancel semantics on the person who manages the struts-config file. When 
the command was not in legacy mode, it would only check for the cancel 
parameter for requests whose Struts action path looks up an 
ActionMapping which has had an explicit value set.


So once this was done, you couldn't bypass validate(), except for 
actions that should be designed to handle it.


Yep, makes sense. +1 for Nico's approach, both for being easier to 
implement and for being the simplest thing that could possibly work (TM) :-)


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Validation Security Hole?

[Laurie Harper]

Transplanted from the user list, w/ Frank's response [FYI, if you 
haven't seen the thread on the user list: this is a summary of 
discussion around the handling of 'cancelled' actions as a potential 
security hole...]


Frank W. Zammetti wrote:
Excellent summary Laurie, thanks!  I think you captured all the 
pertinent information clearly and concisely.  I just suggested to Paul 
to open a ticket for this as well, that should probably be mentioned 
(with a ticket # if available when you post).  Two minor comments below...


Frank

Laurie Harper wrote:
[Moved to a top-level thread, as this doesn't have anything to do with 
(either of) the thread(s) it was nested in! :-)]


Was it nested?  I didn't even notice :)



I think this thread deserves discussion on the dev list, but before I 
move it over I thought I'd post a summary to make sure I've captured 
all the arguments. I've also added preliminary thoughts in how to 
resolve the issue at the end of this post, though that discussion 
definitely ought to proceed on the dev list I guess.


I'll re-post this message to the dev list later today if I haven't 
missed anything important below:




* Issue: addition of a 'org.apache.struts.action.CANCEL' parameter to 
any request will cause validation to be skipped, but the rest of the 
request processing / action invocation cycle to proceed normally


* Consequence: any action which proceeds assuming that validation has 
completed successfully and which doesn't explicitly check isCanceled() 
is proceeding on a broken assumption


* Questions:

- why doesn't Struts call validate() on a cancelled request?

If a request is canceled it usually means validations don't
apply since the implication is that any user input will be
thrown away. Users shouldn't be required to supply valid
inputs for actions they are canceling.

- why does Struts still call Action.execute() for a canceled request?

Since you may still want to act on a canceled request (e.g.
to clean up resources stored in the session). (Some of?) the
DispactAction variants dispatch to a special method and aren't
subject to the consequences listed above, but most action
implementations don't.

- why does Struts still populate the action form on a cancelled request?

If inputs are going to be thrown away anyway, why process
them by populating the action form? [Commentary: I believe
this behaviour makes sense since it preserves a standard
way to access the request data, should you want to, regardless
of whether the action was canceled. You could argue that
either way...]


I tend to agree with your commentary, even though I find it hard to 
envision a situation where you'd want to get at the parameters. 
Certainly better to be able to though.


Here's my first thoughts on possible approaches to addressing the 
problem, to kick off further discussion on the dev list:


- SAF1.2 and before: ? document, don't fix? add config req'm'ts on 
action mapping? Refer to discussion on user list for various options.


- SAF1.3+: make cancel processing a command which you have to include 
in your request processing chain, and perhaps disclude it by default? 
[I'm not familiar enough with how you deploy chains on a per-action 
basis to know if this is the right way to do it...]


I think this would be affected by what is done with 1.2... if it is 
modified to by default not allow Actions to be cancelable for instance, 
I would think it would be better to replicate that change into 1.3, 
which would likely entail changing the default chain.  Open for 
discussion obviously :)


- WW2/SAF2: implement cancel processing as an interceptor and either 
disclude it from default stack or require an action to implement an 
interface declaring that cancel processing should happen?


L.


-
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: Non-discussion emails

[Laurie Harper]

Just to point out the obvious: directing wiki/commit/issue logs to 
separate lists in no way precludes having everything show up on the dev 
list as well. We could have dev-svn@, dev-wiki@, dev-issues@, etc plus 
dev-discuss@ and simply subscribe dev@ to each of those to obtain an 
aggregate.


The only sticky point would be ensuring that replies on dev@ went to the 
appropriate partial list, which should be solvable but would, of course, 
require a little more help from infrastructure.


For that reason Ted's proposal, doing this 'after the fact' in the 
forums, is probably the right short-term solution but I don't think 
there's any technical reason Patrick's requirements can't be met.


L.

Greg Reddin wrote:
There are several things I've been thinking about as this discussion has 
developed.


First, it is true with any craft, but especially with technology, that 
we must always be willing to change when better ways come along.  
Otherwise we stagnate and fade away.  So if I would be more productive 
using these other tools it would be wise for me to consider using them.


However, I can't imagine I would be more productive by having to open an 
RSS reader to follow "the other stuff".  As it is I glance at my email 
several times a day and read what I can and delete the rest (similar to 
James' approach).  I would actually be *less* productive if that 
involved opening up another reader.  The end result is that I'd probably 
not read the commits, wiki updates, and tickets.  Then I would lose 
track with what's going on and fade away.


I'm ok with multiple lists.  I tend to subscribe once and stay 
subscribed.  I could potentially be subscribed from this email address 
for the rest of my life :-)  If that supports both ways, then cool.


You guys have made some good points about the WW merger being a merger 
of communities not just code.  To that end I think there should be 
compromise on both sides to merge the communities and get them working 
together.  However I think one should expect movement on the ASF side to 
be slower and more incremental because we're talking about the whole ASF 
not just Struts.  The other side of that coin is that I hope the WW 
people will bring these new ideas to the table and eventually institute 
change for the better.  Just be aware that this is a slow-moving train.  
That pace is one of the things I enjoy about the ASF.  I can go away for 
a while and when I come back things will likely be in a state where I 
can jump back into familiar territory.


I, for one, will try to embrace the new ideas, but it will take a lot of 
time.  I'd much rather be working on Tiles than figuring out new ways of 
keeping up with the discussions :-)  +1 for the incremental approach Ted 
(I think) proposed.


Greg

On Jan 17, 2006, at 7:45 PM, Patrick Lightbody wrote:

Wow, seems like there is a lot of push back on this topic. All I ask 
Please respect that Jason and I (as well as the WebWork community) 
come from a very well-established open source community and have a lot 
of alternative experience in this area. We both have different 
perspectives, but this merger is more than dumping code in the Struts 
codebase. It is working with the teams too.


To Ted's specific points:

 * I am very well aware the emails are a direct result of a peron's 
action. To my original point: I don't care. I personally review the 
wiki and bug tracker at a different time than when I check email.
 * Jive Forums certainly can filter the email, and I may turn that on, 
but then I've bypassed the team rather than working with them. I don't 
like that approach at all.


To Sean's points:

  * I am not proposing that we get rid of email lists. I am only 
suggesting that there be ways to opt out of certain lists/types of 
mail. Why is offering more options such a problem? I fail to see how 
everything being list-based leads to the conclusion that "The result 
is a single archive that is publicly searchable and contains all 
relevant decisions (no matter how trivial) in one place." Why can't 
there be multiple archives that can all be searched at once? We 
provide that with WebWork by allowing users to search the WebWork 
_category_, which includes the Dev, User, and CVS lists.


To James:

  * I fully support that you work that way and am not suggesting your 
workflow change at all. I 100% support complete email-based 
communication. I only ask that some users such as myself be able to 
opt out.


So, I'd like to propose something. Ted said:



Now, we could create a wiki@ mailing list and an issue@ mailing list,
to match the commit@ list, but now when people opt-in, they have to
opt into five lists instead of three. If we add a Roller blog to the
 mix, then there would be six.



I offer two suggestions, either is perfectly fine with me. Any other 
suggestions that provide more alternatives are also of course welcome:


1) Why not create a simple web-based form to manage all the lists. By 
default, all 5, 6, o

Re: Checkstyle (was svn commit: r360442 [1/3] )

[Laurie Harper]

If the goal is to be able to run a tool to get checkstyle 'conformance' 
wouldn't it be better to tailer checkstyle to a tool anyone could grab, 
rather than tailoring it to what IDEA can do? Don't get me wrong, I love 
IDEA and I'd be quite happy to be able to use it for this, but not 
everyone has IDEA...


+1 in principle, though.

Ted Husted wrote:

It's just that I don't have a lot of time right now to try and get
IDEA or Jalopy to match our CheckStyle setup. If CheckStyle is going
to be held up as the arbitrator of coding style, it would be nice if a
code reformatter could reach the CheckStyle configuration directly.

If anyone would like to volunteer to try and match IDEA's
configuration with our CheckStyle file, that would be very helpful. I
made some changes against the IDEA defaults, but apparently they are
not quite right. I'd like to reduce the coding inconsistencies, but I
don't want to introduce a lot of manual changes right before a
release.

The changes from the IDEA norm I've identified so far are documented
in my comment of 12/31.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36306

Or, alternatively, we could develop a CheckStyle file to match the
IDEA norm, and use that instead. I think the important thing is to
have a coding style that we can enforce with an automatic tool, so as
to not waste volunteer time on mechanical tasks.

-Ted.

On 1/17/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:

You may want to have a look at Jalopy:

jalopy.sf.net

There are plugins for various IDEs and editors, as well as an Ant task
(IIRC, you can use Ant tasks from Maven?).  It won't fix everything, but
it will help enforce many of the more common coding standards.  It
should be possible to configure its rules to match those of CheckStyle,
so you could then use CheckStyle to manually deal with what remains that
Jalopy doesn't fix.

Frank

Don Brown wrote:

It just fills the errors list with checkstyle errors, that you can then
click on to be taken to the file and line.  It was very handy for
cleaning up Scripting.

Don

Ted Husted wrote:


Does it actually reformat the code? Or just report on what should be
reformatted?

On 1/17/06, Don Brown <[EMAIL PROTECTED]> wrote:



I've been using jEdit's checkstyle plugin.  I had to temporary modify
the checkstyle xml to remove those dynamic properties, but otherwise, it
worked great.

Don

Ted Husted wrote:



Is anyone using an automatic code reformatting tool that can read a
CheckStyle configuration?

I'd like to clean up some of the stylistic errors, but I would prefer
that most of the reformatting be done by a proven tool. I have utter
confidence in IDEA, but I don't know if we can perfectly align the
settings with CheckStyle.

For more, see

* http://issues.apache.org/bugzilla/show_bug.cgi?id=36306

Having CheckStyle standards is great, but I would rather have a
consistent code style that we can enforce with an automatic
reformatting tool.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 1.3.0 Release - Next Steps

[Laurie Harper]

I hate to say it, but I'm not going to have time to work on fixing  
this in time for the 1.3 release. Wendy's suggestion (removing the  
feature for now) probably makes the most sense; I'll look at adding  
the serialization support and putting the enhanced form bean support  
into 'extras' post 1.3.0.


L.

On 16-Jan-06, at 7:27 PM, Ted Husted wrote:


Any new input on #37730?

If we are not ready to resolve the serialization issue, then we should
table this new feature for a subsequent release.

-Ted.

On 1/13/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
Bug# 37301 looks like an enhancement request to me... I don't  
think it

should prevent a release.  So we just need to resolve Bug #37730
(serialization) one way or the other.  Laurie, any comments on all
this?


--
Laurie Harper
Open Source advocate, Java geek: http://www.holoweb.net/laurie
Founder, Zotech Software: http://www.zotechsoftware.com/




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Removing CGLIB enhancement from struts-action

[Laurie Harper]

I only saw Ted's message on this in my personal inbox, not here on the 
list, so in case my reply to that doesn't get through to here:


+1 -- I unfortunately wont have time to address #37730 in the 1.3.0 
timeframe :-( I'll revisit the feature when I have some spare cycles [I 
get away with using this feature as-is because I don't put form beans in 
session scope, but that's clearly not a reasonable restriction for the 
release].


L.

Wendy Smoak wrote:

I really don't like doing this. :(  I'm happy to hear alternatives.

This is a proposal to remove CGLIB enhancement from Struts Action. 
Bug# 37730 "Enhanced DynaActionForms cannot be correctly deserialized"

[0] remains unresolved and is holding up the 1.3.0 release plan.  I'd
like to remove this in order to allow us to move forward with the
release.

The proposed patch is here:
   http://people.apache.org/~wsmoak/struts-action/cglib/remove-cglib.diff

I left the 'enhanced' attribute in the DTD with the comment 'Reserved
for future use' so that if a solution is found it can still be part of
1.3.

Ted suggested moving this to the sandbox extras project but as it
involves changes to core classes I can't really "move" it like I did
with the commons-resources dependency.  With Subversion, though,
nothing is ever really gone.

Thoughts?

[0] http://issues.apache.org/bugzilla/show_bug.cgi?id=37730

--
Wendy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [shale] DefaultViewControllerMapper limitations

[Laurie Harper]

Craig McClanahan wrote:

On 1/5/06, Laurie Harper <[EMAIL PROTECTED]> wrote:

Craig McClanahan wrote:

On 1/5/06, Laurie Harper <[EMAIL PROTECTED]> wrote:

Thanks to my unusual use of view identifiers carrying path-extra-info
information, I've discovered a bit of a limitation with
DefaultViewControllerMapper: if the result of applying the mapping
algorithm isn't legal as a value binding expression, you get an ugly
stack trace. I triggered this because I have view identifiers which may
include spaces or other 'special' characters which, to be fair, the
Javadoc explicitly states you shouldn't do :-)


There are some alternative ways to code a VB expression that might deal

with

some of these issues.  It centers around the fact that, in EL

expressions

(as in JavaScript), the following two expressions do the same thing:

foo.bar

foo['bar']

so if the "bar" part of your expression has characters that would mess

you

up ... a period is the most common one that I've run into ... use the

latter

syntax.  This is paticularly handy, for example, when using

,

where the message keys in your properties file have periods in them:


...


Looking at the bigger picture, any mapper implementation that's not

well-behaved (in terms of returning a value that can be turned into a
value binding) is going to cause this behavior.

I thought it'd be a simple case of catching the exception when the

value

binding expression is created (ReferenceSyntaxException from
createValueBinding() or EvaluationException from getValue()), but it
looks like the EL implementation I'm using (from Facelets) is throwing
an implementation exception rather than the correct, documented
exception -- I'm getting a com.sun.faces.el.impl.ElException from
createValueBinding() (using the RI).

Is there any clean way to deal with this, since catching
com.sun.faces.el.impl.ElException in Shale isn't really appropriate...


See above.

You're talking about either changing what's in the view ID, or changing
how it's mapped. Both of those will fix the problem on a case-by-case
basis, sure.

What I was getting at was more, can we make it so that a 'bad' view
controller name doesn't cause a blow-up? What I was going to propose was
changing ShaleViewController's setupViewController() method (and other
places which use the mapping manager) something like this:

 // Retrieve an existing instance, or one created and configured
by
 // the managed bean facility
-   ValueBinding vb =
-   context.getApplication().createValueBinding("#{" + viewName
+ "}");
 ViewController vc = null;
 try {
+   ValueBinding vb =
+   context.getApplication().createValueBinding("#{" +
viewName Object vcObject = vb.getValue(context);
 if (vcObject == null) {
 log.warn(messages.getMessage("view.noViewController",
  new Object[] { viewId,
viewName }));
 return;
 }
 vc = (ViewController) vcObject;
 } catch (ClassCastException e) {
 log.warn(messages.getMessage("view.notViewController",
  new Object[] { viewId,
viewName }));
 return;
+   } catch (ReferenceSyntaxException e) {
+   // ... log an error/warning and return
+   } catch (EvaluationException e) {
+   // ... log an error/warning and return
 }

The rationale is that

a) Shale users may plug in a naive or broken mapper; it'd be nicer to
fail gracefully, letting them know what the problem is, rather than
throw an exception

b) Third-party component libraries may (I think?) include navigation
rules in their bundled faces-config that point to view IDs which don't
conform to the constraints of whatever mapper may be installed



Something like this does make sense ... let's be as explicit as we can when
we run into probems.

That being said, in this case its still something *we* (Shale) are doing, by
composing a value binding expression that might not be valid.  It's also
worth figuring out if we can use an alternate syntax so that a vew
identifier like "foo.bar" would still work.

But ... wait ... its even easier than that.  We should be using the
VariableResolver directly, instead of composing a value binding expression.
This won't care about the syntax, and will be a bit more efficient to boot.


So the variable resolver can look up variable names that contain 
arbitrary strings? That might work better.


Something that doesn't work as a value binding expression isn't going to 
be useble in your views for referencing the view controller, of course, 
but that's already a problem and at least it's proba

Re: [shale] DefaultViewControllerMapper limitations

[Laurie Harper]

Craig McClanahan wrote:

On 1/5/06, Laurie Harper <[EMAIL PROTECTED]> wrote:

Thanks to my unusual use of view identifiers carrying path-extra-info
information, I've discovered a bit of a limitation with
DefaultViewControllerMapper: if the result of applying the mapping
algorithm isn't legal as a value binding expression, you get an ugly
stack trace. I triggered this because I have view identifiers which may
include spaces or other 'special' characters which, to be fair, the
Javadoc explicitly states you shouldn't do :-)



There are some alternative ways to code a VB expression that might deal with
some of these issues.  It centers around the fact that, in EL expressions
(as in JavaScript), the following two expressions do the same thing:

foo.bar

foo['bar']

so if the "bar" part of your expression has characters that would mess you
up ... a period is the most common one that I've run into ... use the latter
syntax.  This is paticularly handy, for example, when using ,
where the message keys in your properties file have periods in them:


...


Looking at the bigger picture, any mapper implementation that's not

well-behaved (in terms of returning a value that can be turned into a
value binding) is going to cause this behavior.

I thought it'd be a simple case of catching the exception when the value
binding expression is created (ReferenceSyntaxException from
createValueBinding() or EvaluationException from getValue()), but it
looks like the EL implementation I'm using (from Facelets) is throwing
an implementation exception rather than the correct, documented
exception -- I'm getting a com.sun.faces.el.impl.ElException from
createValueBinding() (using the RI).

Is there any clean way to deal with this, since catching
com.sun.faces.el.impl.ElException in Shale isn't really appropriate...



See above.


You're talking about either changing what's in the view ID, or changing 
how it's mapped. Both of those will fix the problem on a case-by-case 
basis, sure.


What I was getting at was more, can we make it so that a 'bad' view 
controller name doesn't cause a blow-up? What I was going to propose was 
changing ShaleViewController's setupViewController() method (and other 
places which use the mapping manager) something like this:


// Retrieve an existing instance, or one created and configured by
// the managed bean facility
-   ValueBinding vb =
-   context.getApplication().createValueBinding("#{" + viewName 
+ "}");

ViewController vc = null;
try {
+   ValueBinding vb =
+   context.getApplication().createValueBinding("#{" + 
viewName Object vcObject = vb.getValue(context);

if (vcObject == null) {
log.warn(messages.getMessage("view.noViewController",
 new Object[] { viewId, 
viewName }));

return;
}
vc = (ViewController) vcObject;
} catch (ClassCastException e) {
log.warn(messages.getMessage("view.notViewController",
 new Object[] { viewId, 
viewName }));

return;
+   } catch (ReferenceSyntaxException e) {
+   // ... log an error/warning and return
+   } catch (EvaluationException e) {
+   // ... log an error/warning and return
}

The rationale is that

a) Shale users may plug in a naive or broken mapper; it'd be nicer to 
fail gracefully, letting them know what the problem is, rather than 
throw an exception


b) Third-party component libraries may (I think?) include navigation 
rules in their bundled faces-config that point to view IDs which don't 
conform to the constraints of whatever mapper may be installed


I guess it could just be 'catch Exception' but that seems a little 
over-protective ;-)


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[shale] DefaultViewControllerMapper limitations

[Laurie Harper]

Thanks to my unusual use of view identifiers carrying path-extra-info 
information, I've discovered a bit of a limitation with 
DefaultViewControllerMapper: if the result of applying the mapping 
algorithm isn't legal as a value binding expression, you get an ugly 
stack trace. I triggered this because I have view identifiers which may 
include spaces or other 'special' characters which, to be fair, the 
Javadoc explicitly states you shouldn't do :-)


Looking at the bigger picture, any mapper implementation that's not 
well-behaved (in terms of returning a value that can be turned into a 
value binding) is going to cause this behavior.


I thought it'd be a simple case of catching the exception when the value 
binding expression is created (ReferenceSyntaxException from 
createValueBinding() or EvaluationException from getValue()), but it 
looks like the EL implementation I'm using (from Facelets) is throwing 
an implementation exception rather than the correct, documented 
exception -- I'm getting a com.sun.faces.el.impl.ElException from 
createValueBinding() (using the RI).


Is there any clean way to deal with this, since catching 
com.sun.faces.el.impl.ElException in Shale isn't really appropriate...


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Struts/WebWork Merger Tasks (was Q)

[Laurie Harper]

Ex-party sidebar: how much value do DyanBeans add in WW given that, if I 
understand correctly, it can already work directly with POJOs? The thing 
that dyna action forms are there to avoid (writing boilerplate action 
forms) isn't needed in WW is it?


L.

Don Brown wrote:

Off the top of my head:

 - Wildcards
 - Chain command executed from Interceptor (like ChainInterceptor)
 - Chain command executed as Action (an alternate implementation of 
ActionInvoker)

 - DynaBean support in ognl
 - Package properties support (debatable)

Don

Patrick Lightbody wrote:

Duh, sorry about that. It's been a slow day :)

Can we talk about more about #7? I think #7 is where the majority of  
the time (debate time or development time) will be spent. What items  
do you guys have in mind?


Patrick

On Jan 5, 2006, at 12:05 PM, Ted Husted wrote:


On 1/5/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:


I know there are a few features (probably more) that we'd like to
bring forward from Struts Action 1.x to 2.x that aren't in WebWork
already. For example, the wildcard support in configuration.

Where does that fit in? This current schedule looks like 2.0.0 would
be basically WebWork 2.2 + migration tools. Is the plan to add the
extra features, like wildcards, to Struts Action 2.1? I'm find with
either, but my understanding was that we'd do additional development
between WW 2.2 and SAF 2.0.



That would be item # 7.


 7. Migrate Struts features as desired (chain support, wildcards,  etc)



We're going to need at least two phases of development between WW 2.2
and SAF 2.0.0.

First, we need to replace the LGPL dependencies and resolve any other
IP/Incubator issues  (Item #2).

Second, we would add any missing features, like wildcardmappings  
(Item #7).


Of course, some of this will be asynchronous. Don and Rich are doing
some early work on tools now, but those would change as we add missing
features.

-T.

-
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]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [shale] Proposal: making view controllers easier to access

[Laurie Harper]

Craig McClanahan wrote:

On 12/31/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

Craig McClanahan wrote:

On 12/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

One thing I'm finding a little ugly using Shale is referencing the view
controller using EL expressions. Due to the way Shale maps view IDs to
backing bean names, I end up with ugly EL expressions like
#{pages$user$profile$general.whatever}.

Would it make sense to store the view controller under a well-known
(configurable) key, so you could instead write #{backing.whatever}?
Shale could use a standard name (e.g. 'backing') by default and provide
a configuration option to change this to whatever the developer wants.

There could also be a mechanism for setting the 'alias' on a per-view
basis; perhaps an interface the view controller bean can optionally
implement which would return the backing bean alias and/or allow it to
be set as a managed property.


Are you thinking of something that would let the *bean* say what *page*

it

is the controller for (rather than the other way around, as you

currently

do)?  That would probably be feasible -- especially in the optional

Shale

Tiger library, where we could use annotations for that

purpose.  However,

the text of your views (in particular, the value binding expressions in

your

components) are going to *have* to know the managed bean name of the
corresponding backing bean anyway.  So, it doesn't seem like it would

add a

lot of value.

Eep! No :-) I meant a way for the bean to say what 'value binding alias'
it should be exposed under. So ShaleViewController would create a value
binding that allowed the controller to be refered to a
#{backing.whatever} by default, but a particular controller bean could
cause something other than 'backing' to be used.



The tiger extension stuff can do that, but (since it is really using JSF
managed beans under the covers) there could still only be one bean class for
a particular alias, using the current mapping architecture.  Thnking about
it some more, that means you can't even achieve sharing a particular
attribute key for all the view controllers at all -- the way things are
architected today -- even by replacing the ViewControllerMapper.


You're talking about using annotations to drive the mapping manager, 
right? Yeah, I can see how that would be useful in a different context, 
but I don't think it applies here (see below).



Are there situations that would make this a Really Bad Idea?

One scenario where sharing a common request scope attribute would create

a

limitation (versus current behavior) is you would not be able to have

more

than one active view controller on a page.  With subviews, it is

convenient

to have a view controller per Tile, for example.

Hmm, I don't know about 'subviews' yet :-) But I think I get the point;
if you have more than one view (JSP etc.) rendered as part of a single
request, the view controllers would 'collide' using this idea, is that it?


Yep.


OK, now I understand the issue.


If you don't like the current mapping algorithm, by the way, you're free
to

change it :-).  Simply create your own implementation of
ViewControllerMapper and register it (in application scope) under the

key

identified by ShaleConstants.VIEW_MAPPER.

Given the above limitation, that might be a better idea then.


Except it won't give you what you want :-(.  That would take a different
sort of mapping approach, which might require something other than managed
beans to actually create the beans in question, which is kinda going away
from the original direction ...


Yeah, I didn't think it through. I'm fine with the current mechanism for 
resolving a view ID to a controller instance.





I'm

wondering if it might cause issues for view composition with Clay, for
example.

I don't think any of the mapping issues care what view technology you

are

actually using, although Clay does provide a mechanism to do

substitutions

on the "@managed-bean-name" symbol for you when it constructs the page.

To be clear, I wasn't proposing changing the existing mapping mechanism
at all, only augmenting it such, that *in addition to* referencing
#{foo$bar$baz.whatever} as you can you, you could also write
#{backing.whatever}.



Now that might be a more interesting alternative ... change the custom
variable resolver's mechanism for figuring out what "backing" means ... then
it could work for Clay or non-Clay view rendering.


Right, I think we're more or less on the same page now ;-) A custom 
variable resolver sounds like it might be a reasonable way to go. 
There'd need to be some way for it to be aware of the current 
view/subview so it could resolve the name 'backing' the the view 
controller for the current view.


Actually, it's even simpler than that: a

Re: Rép : [shale] Proposal: mak ing view controllers easier to access

[Laurie Harper]

Gary VanMatre wrote:
From: Laurie Harper <[EMAIL PROTECTED]> 

Gary VanMatre wrote: 
From: Alexandre Poitras 

Ok but I still don't get it. From what I understand, you couldn't not 
use for example @a or 
@ab because they share the first same letter. That what I found when I 
took a quick look in the sources but I could be wrong. And since 
symbols are inherited that's not a lot. I guess I am probably not 
getting something here. 

No, you have a very good point and I didn't mean to seem as if I'm discounting 
it. It is a limitation but my opinion is that you can come up with a easy 
conventions for making unique names. 
Consider @[EMAIL PROTECTED] This is valid using the current substitution mechanism. (I 
just realized this myself :-). 

I just posted a comment on the bug which suggested the equivalent (I 
suggested @[EMAIL PROTECTED], similar to shell variable substitution, but it's 
the same difference). Looks like the problem's already addressed :-) 



I think we have it covered but it's not necessary a solution that was part of the initial thought behind the design but it seems to work out anyway.  I'll close this ticket if we feel this is an except able solution.  


The only thing I'd point out is the possible confusion between [] as a 
token separator for Clay symbols and [] as an indexing operation in a 
value binding expression. I don't know whether that's a real concern, 
but a non-overlapping syntax may reduce questions as Clay gets used more 
widely.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Rép : [shale] Proposal: mak ing view controllers easier to access

[Laurie Harper]

Gary VanMatre wrote:
From: Alexandre Poitras <[EMAIL PROTECTED]> 

Ok but I still don't get it. From what I understand, you couldn't not 
use for example @a or 
@ab because they share the first same letter. That what I found when I 
took a quick look in the sources but I could be wrong. And since 
symbols are inherited that's not a lot. I guess I am probably not 
getting something here. 



No, you have a very good point and I didn't mean to seem as if I'm discounting it. It is a limitation but my opinion is that you can come up with a easy conventions for making unique names. 

Consider @[EMAIL PROTECTED] This is valid using the current substitution mechanism. (I just realized this myself :-).  


I just posted a comment on the bug which suggested the equivalent (I 
suggested @[EMAIL PROTECTED], similar to shell variable substitution, but it's 
the same difference). Looks like the problem's already addressed :-)


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [shale] Proposal: making view controllers easier to access

[Laurie Harper]

Craig McClanahan wrote:

On 12/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

One thing I'm finding a little ugly using Shale is referencing the view
controller using EL expressions. Due to the way Shale maps view IDs to
backing bean names, I end up with ugly EL expressions like
#{pages$user$profile$general.whatever}.

Would it make sense to store the view controller under a well-known
(configurable) key, so you could instead write #{backing.whatever}?
Shale could use a standard name (e.g. 'backing') by default and provide
a configuration option to change this to whatever the developer wants.

There could also be a mechanism for setting the 'alias' on a per-view
basis; perhaps an interface the view controller bean can optionally
implement which would return the backing bean alias and/or allow it to
be set as a managed property.



Are you thinking of something that would let the *bean* say what *page* it
is the controller for (rather than the other way around, as you currently
do)?  That would probably be feasible -- especially in the optional Shale
Tiger library, where we could use annotations for that purpose.  However,
the text of your views (in particular, the value binding expressions in your
components) are going to *have* to know the managed bean name of the
corresponding backing bean anyway.  So, it doesn't seem like it would add a
lot of value.


Eep! No :-) I meant a way for the bean to say what 'value binding alias' 
it should be exposed under. So ShaleViewController would create a value 
binding that allowed the controller to be refered to a 
#{backing.whatever} by default, but a particular controller bean could 
cause something other than 'backing' to be used.



Are there situations that would make this a Really Bad Idea?



One scenario where sharing a common request scope attribute would create a
limitation (versus current behavior) is you would not be able to have more
than one active view controller on a page.  With subviews, it is convenient
to have a view controller per Tile, for example.


Hmm, I don't know about 'subviews' yet :-) But I think I get the point; 
if you have more than one view (JSP etc.) rendered as part of a single 
request, the view controllers would 'collide' using this idea, is that it?


Does JSF support page scope? I'm guessing not, as that's a JSP-specific 
concept.



If you don't like the current mapping algorithm, by the way, you're free to
change it :-).  Simply create your own implementation of
ViewControllerMapper and register it (in application scope) under the key
identified by ShaleConstants.VIEW_MAPPER.


Given the above limitation, that might be a better idea then.


I'm

wondering if it might cause issues for view composition with Clay, for
example.


I don't think any of the mapping issues care what view technology you are
actually using, although Clay does provide a mechanism to do substitutions
on the "@managed-bean-name" symbol for you when it constructs the page.


To be clear, I wasn't proposing changing the existing mapping mechanism 
at all, only augmenting it such, that *in addition to* referencing 
#{foo$bar$baz.whatever} as you can you, you could also write 
#{backing.whatever}.


How does Clay resolve the conflict you described above to resolve 
@managed-bean-name correctly when used with subviews? Could the same 
strategy work outside of Clay, or is it too deeply bound up in Clay's 
render model?


L.


Assuming there aren't major drawbacks to the idea, I'll try and work up

a patch in the next day or so covering some or all of the points above.

Cheers,

L.



Craig




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[shale] Proposal: making view controllers easier to access

[Laurie Harper]

One thing I'm finding a little ugly using Shale is referencing the view 
controller using EL expressions. Due to the way Shale maps view IDs to 
backing bean names, I end up with ugly EL expressions like 
#{pages$user$profile$general.whatever}.


Would it make sense to store the view controller under a well-known 
(configurable) key, so you could instead write #{backing.whatever}? 
Shale could use a standard name (e.g. 'backing') by default and provide 
a configuration option to change this to whatever the developer wants.


There could also be a mechanism for setting the 'alias' on a per-view 
basis; perhaps an interface the view controller bean can optionally 
implement which would return the backing bean alias and/or allow it to 
be set as a managed property.


Are there situations that would make this a Really Bad Idea? I'm 
wondering if it might cause issues for view composition with Clay, for 
example.


Assuming there aren't major drawbacks to the idea, I'll try and work up 
a patch in the next day or so covering some or all of the points above.


Cheers,

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: A hint in html:select

[Laurie Harper]

Lotfi Ramdani wrote:

HI all,

I want to use hint to Show some text when my mouse over an itel of my Select
liste.

How can I do it.

Is there a solution with javascript.


Firstly, this sort of question should be asked on the user list; the dev 
list is for discussion of the development of Struts projects.


As to your question, if by 'show some text' you mean you want the 
browser to display a 'tooltip', you're probably looking for something 
like the HTML 'title' attribute. Unfortunately, the html:option tag and 
its friends don't have any support for this. A Javascript solution 
(using onmouseover for example) is also not possible using html:option.


So, if this was what you were looking for, you'd have to write HTML 
'option' tags directly, rather than using Struts' HTML tags.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT] Appropriate logging (was IDE Haters (Was Re: Logging in MailReader 1.3))

[Laurie Harper]

Is this taking the discussion further off topic or bringing it back 
towards it's starting point? ;-) Frank's comments below go more to the 
heart of what logging should or shouldn't be used for, which has been a 
bug-bear of mine for a while...


The key thing is to remember, when writing log statements, who will be 
*reading* them. There are three groups to consider: the developer, the 
'end user admin' (i.e. your customer's admin guy, etc.) and, when 
something breaks in an unexpected way, the tech support staff.


The log should be 99% things that make sense to the 'end user admin' guy 
-- in other words, it should contain logging messages that tell them 
things they need to know, either to verify the system is working 
correctly or to figure out how to fix it w/out calling tech support.


Anything that's only meaningful to someone who has the source code to 
look at should be debug/trace level, and shouldn't be enabled by 
default. Those logs are for the developer during the code/test cycle, or 
during post-production diagnostic exercises. That can be an important 
thing to be able to turn on in production if you can't reproduce a 
problem in a test environment, but they're only interesting to someone 
responsible for diagnosing and/or fixing a problem.


The third group, tech support staff, is sort of a cross-cutting concern 
;-) I generally use 'info' level logging for this sort of thing. Stuff 
like logging life-cycle events and key changes in overall system state. 
The goal is to allow someone with sufficient familiarity with how the 
app should be running to spot why it's not behaving in an expected way 
*assuming the problem is not a bug*. In other words, it lets first level 
technical support figure out that feature X isn't working because config 
options Y has the wrong value. Debug and trace level logging shouldn't 
come into it until tech support has escalated the problem to engineering 
and the dev team, after examining all the logs, realizes that they can't 
tell what's gone wrong ;-)


Of course in Mailreader, all three roles collapse into one (more or 
less). And, since the logging is there mainly to let someone correlate 
the code with what happens when they run it, it's mostly there as trace 
I suspect (not having looked at the code...)


L.

Frank W. Zammetti wrote:
My tact has always been that trace statement should only be used to 
trace entry, and perhaps exit, from a method.  Anything within a method 
is either debug or info as appropriate, with error and fatal being 
self-explanatory.


My reasoning is simply that if I have a particularly thorny issue I'm 
trying to work out, I like having a complete trace where the code went, 
and especially when its in log format I can print it out and take it to 
lunch to trace through if need be.  Frequently you only really need the 
debug messages though.


Don's comment about leaving "Action was called"-type statements to the 
framework is reasonable.  I would typically have a trace message as the 
first thing in an Action, just because I don't want to absolutely trust 
that the Action was actually called, i.e., maybe the log message where 
the framework says Action A is being called has three lines between it 
and the actual call, in which case it could be misleading.  I wouldn't 
go nuts if I didn't see such a trace message though.  Should it be 
considered a "best practice" to have such a message?  I could argue that 
a user of a framework doesn't necessarily know what logging the 
framework itself will put it and therefore they shouldn't assume they 
will get what they need.  It's a debatable point though.


My other tact is that I put a debug message in before and sometimes 
after a statement that I know could fail, or more importantly that might 
not itself fail but that could blow something up down the line.  Many 
times this isn't just "about to do something dangerous"... for instance, 
in the call to doGetUser() below, assuming that might fail if session 
was null, I might put:


log.debug("Getting user from session " + session):

...before it, and then:

log.debug("user = " + user);

...after it.

In fact, the second one I might put at info level... when an app is in 
production, nothing is more annoying than when a problem occurs and you 
realize you aren't logging enough to get anywhere in solving it!  Of 
course your going to try and replicate it in a dev/QA environment with 
full logging on, but how many times does a user complain about something 
and you can't replicate it?  Then, whatever logging the app does at 
production level is all you have.  Naturally, prudency is important though.


Frank

Ted Husted wrote:

On 12/9/05, Don Brown <[EMAIL PROTECTED]> wrote:

I'd like to see the logging taken down a notch, but perhaps not 
completely out.
 IMO, Mailreader is there to demonstrate Struts best practices and 
the logging
statements everywhere make one wonder :)  Besides, it gives a false 
impression
Actions need to be long 

Re: [ti] Struts Action 1.x migration tools

[Laurie Harper]

Don Brown wrote:
I've gone back and forth how and to what level of detail Struts Ti 
can/should support Struts Action 1.x applications.  When I say Struts 
Ti, at this point, I'm referring to WebWork 2.2 since we haven't 
imported the code yet.  Below is my thoughts that I invite comments on.


Basically, I see three ways to approach Struts Action 1.x (hereby 
referred to simply as 1.x) support in Struts Ti: graph 1.x into Struts 
Ti, develop tools/libraries to help the two frameworks co-exist, and 
simply include the latest release of 1.x with Struts Ti as is.


1. Graph 1.x into Struts Ti - This approach tries to take 1.x code and 
restructure it as Ti objects.  For example, we'd
 - Create a subclass of Configuration to which would expose 1.x 
configuration files
 - Recode the 1.x chain commands as interceptors or at least an 
interceptor that calls a chain

 - Develop a custom interceptor to plug in commons validator
 - Write a custom ActionInterceptor and ActionProxy to call Struts Actions
 - Add a custom ObjectFactory to create 1.x Actions correctly
 - Rewrite the taglibs to pull data Ti-style

Advantages: From a users perspective, you'd be (hopefully) run your 1.x 
application as is, yet gradually take advantage of Ti features on a per 
Action basis.


Disadvantage: A ton of work, and more than likely, there would be gaps 
in 1.x features or at a minimum, certain things wouldn't work quite 
right, especially for more advanced 1.x applications.


2. Develop tools/libraries to help both frameworks to co-exist better - 
First, we'd include the latest release of 1.x with Struts Ti.  Then, 
we'd create optional extensions to both frameworks that allows them to 
share information.  For example, we'd write:
 - A Ti interceptor that would make available the Struts message 
resource bundles to Ti Actions and pages
 - A Commons Validator interceptor to allow Ti Actions to re-use 
validation configuration files
 - An Ant task that converts a Struts configuration file into a Ti 
configuration file, logging where certain features don't quite match up

 - A way to use Dynabeans with Ti ModelDriven Actions
 - A tiles Result type to allow Ti apps to use Tiles

Advantages: We don't pretend to run 1.x apps directly on Ti, yet by 
providing 1.x jars, we can provide 100% backwards compatibility with 
1.x.  Legacy 1.x apps can start to use Ti gradually, yet not be required 
to duplicate information.  Should take much less time the option #1.


Disadvantages: The collection of tools would require additional 
configuration to use.


3. Only include the latest release of 1.x - In this case, Ti doesn't do 
anything to help migration outside of documentation.  We could still run 
1.x apps, but assume apps using Ti will be rewritten anyways


Advantages: Can run 1.x apps.  Easy.  1.x apps might not even be 
planning to migrate in pieces anyways.


Disadvantages: No support for gradual 1.x migration.

---

Of the three, I'm in favor of the middle one.  I've tried different 
methods of graphing the code together, but while it would be possible to 
run simple 1.x apps, any more complicated ones, the very ones that need 
migration assistance, would find all sorts of hidden problems. 
Furthermore, it still require devs to change their app to at least use 
the new Servlet.


I think including 1.x with Ti is important because it shows we are 
committed to 1.x support and Struts is still a one-stop-shop.  This also 
allows us to change things like customize the chain to aid the 
co-existence support unseen to the user.  1.x is getting quite flexible 
with commons chain so we could take advantage of that here.


Finally, I do think migration tools are important.  The primary 
migration use case I imagine is a user with a 1.x application that might 
need a new module or section.  Instead of writing it with 1.x, they 
might want to try Ti, so they'd add the Ti filter and code up the 
section as a Ti package with its own namespace.  This user wouldn't want 
to duplicate all their message bundles or perhaps even their validation 
configuration.


One of the strongest features Ti has going for it is the possibility for 
a smooth migration for 1.x applications.  How can we best provide this 
for the 1.x user?


Don


I have to ask if the goal behind 1 through 3 is the right goal... In 
other words, should the goal be


 1 - allow a Struts 1.x app to run unchanged on Ti
 2 - allow a Struts 1.x app to run unchanged on Ti, w/ some caveats
 3 - allow a Struts 1.x app to run on Ti, with only minor changes
 4 - allow a Struts 1.x app to run on Ti, with a well defined set of
 migration changes, possibly supported by automated tools

I thought there was a general leaning towards something more like 4, 
with a corresponding minimization of code in Ti solely for the sake of 
1.x compatibility. IMHO the right balance would be somewhere between 3 
and 4; 1 and 2 impose a higher burden on Ti than should be expected or 
required of a 'Struts 2.0'.

Re: [VOTE] Confirm Shale 1.0.0 Test Build Release Plan

[Laurie Harper]

+1 (non-binding)

L.

Craig McClanahan wrote:

All of the outstanding issues have been accounted for -- it's time to
release the initial test build of Shale!  Given the amount of time since the
1.0.0 release plan was first proposed, I'd like to call for a vote
confirming it:

  http://wiki.apache.org/struts/ShaleRelease100

At this time, I would ask the PMC, committers, and other interested parties
to review the plan, and the state of the repository, and indicate your
acceptance of the plan in the usual way (+1, +0, -0, -1) along with
appropriate comments.

This vote will run from now (approximately 2pm Pacific time on Thursday,
12/01/2005) for 96 hours, until 2pm on Monday, 12/05/2005) -- four days
instead of three because of the weekend.  If the plan is accepted, I intend
to post the 1.0.0 build on Monday.

This is not a vote on the quality of the release itself.  I expect that this
release will not graduate beyond alpha quality (due in part to dependence on
an unreleased Standalone Tiles component, but also to correctly set
expectiations for API stability).

Here's my +1 to kick things off.

Craig




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Standalone Tiles] Major Refactoring (Long)

[Laurie Harper]

Wendy Smoak wrote:

I'm planning to work on the Maven build.  Some combination of getting
the version number into the filename (I think right now it should be
tiles-core-0.2-SNAPSHOT) and possibly adding a third piece to the
version number should allow us to publish snapshots that don't get
overwritten.

If someone has already done this with Maven, let me know and save me
some reasearch. :)  So far I haven't had occasion to publish/deploy a
build with Maven, we've just been copying the jars into the right
place for the internal repo.


I'm no Maven guru but as far as I understand, SNAPSHOTs are specifically 
an unversioned artifact which you build and deploy with variants of 
jar:install etc. Maven will automatically ignore the version in 
project.xml and use -SNAPSHOT instead in the artifact file names.


I expect that you could include -SNAPSHOT explicitly in project.xml, but 
it might confuse people used to the 'Maven way'. Of course you know 
Maven far better than me in general; this is just one of those things 
that always struck me about Maven. I can't see why I would ever want to 
depend on a SNAPSHOT build unless I built it myself (or ever want to see 
one in a public repository, for that matter), since there's no telling 
where it came from in terms of code history.


Just my humble opinion, but I'd suggest only publishing things with a 
version number or date stamp or something and letting people either 
build from source or download and locally deploy a nightly if they want 
something different...


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Milestones proposal: Step 1

[Laurie Harper]

There does need to be a distinction, though, between 'probably never' 
and new tickets, not yet assigned to a milestone. I'm not that familiar 
with Bugzilla, though; maybe the Status field is enough to handle that?


L.

Don Brown wrote:
In my opinion, it would be simpler to assign those tickets to the next 
major/minor release, forcing developers to assess when that milestone is 
on deck whether the ticket will actually get fixed in this one or moved 
further down. The problem with this "1.1 Family" is evident in Bugzilla 
where we have a bunch of tickets still assigned to the 1.2.x family.  I 
think these family categories are just corners where tickets go to hide 
and be forgotten.


Personally, I think even a "Future" or "TBD" milestone clouds the issue, 
but it would be a good compromise.  What I'm going for is tickets are 
only assigned to a milestone when someone steps up and says they'll fix 
them or the community agrees it is a requirement of the milestone.


As for the "probably never" tickets, just sitting in Bugzilla not having 
a milestone will be enough to keep them from the casual project view 
(assuming we put in place a clean roadmap).


In general, I think the most simple solution will be the one that lives 
the longest and brings the most clarity.


Don

Ted Husted wrote:

On 12/1/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:


Did we agree anything on bugs which we don't want to allocate to a
milestone - my preference is a "probably never" or "un-allocated"
milestone - something we can query on. Personally I don't like "LATER"
resolutions - IMO thats not a "resolution".



In my own project, we have a major release pseudo-release for issues
that we haven't allocated yet, and then true mliestone releases for
issues that'ave we have allocated, so the JIRA map looks like this:

[Unreleased] 2.x ( Release Notes)
Progress:  [Unresolved Issues - 100% (4 issues)]

  0 of 4 issues have been resolved
New Feature (Story) WNE-77 UNRESOLVED A user by any other 
role

New Feature (Story) WNE-76 UNRESOLVED Attachments
New Feature (Story) WNE-75 UNRESOLVED Multiple comment
New Feature (Story) WNE-44 UNRESOLVED Optimistic locking

[Unreleased]   2.0.16  ( 2005-Dec-13  | Release Notes) 
Progress:  [Resolved Issues - 9% (1 issues)] [Unresolved Issues -

90% (10 issues)]
  1 of 11 issues have been resolved
New Feature (Story) WNE-16 UNRESOLVED Add Facility Mandate
New Feature (Story) WNE-19 UNRESOLVED Delete an Action and 
a Violation
New Feature (Story) WNE-84 UNRESOLVED Meeting Table





So, "2.x" is the "undecided" category for our 2.x release series.

-Ted.

-
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: [PROPOSAL] Target tickets to milestones and use as roadmap

[Laurie Harper]

+1 (non-binding). Definitely a good way to add a lot more clarity about 
where things stand and what needs doing.


L.

Don Brown wrote:
I propose we use an automated, easy to understand roadmap that relies on 
Bugzilla tickets marked against Milestones.


With all the action in the Struts project lately, it is hard to see what 
is going on where, and specifically, qualitatively how much work remains 
before a Milestone will be reached.  We need a system that makes it easy 
to see at a glance the roadmap of each Struts subproject, and guide new 
contributions.


I see the solution involving the following:
 1. All tickets, bugs and enhancements, should be marked against a 
Milestone if accepted
 2. Any major feature or bug fix committed to svn should have a ticket 
and be assigned to a milestone.
 3. A ticket should only be marked against a Milestone if a developer 
has committed to work on it
 4. Once all the all the tickets against a Milestone have been resolved, 
the release is ready to be rolled.


The public face of this solution will be automated roadmap pages, which 
will be generated from Bugzilla reports.  These pages will show, at a 
glance, the status of each subproject, its milestones, and current 
progress toward reaching them.


I've developed a Java console app, driven by a cron, which screen 
scrapes Bugzilla reports to generate a roadmap [1].  As you can see from 
the demo, we don't currently use milestones much at all.  The roadmap is 
an idea taken from Trac [2] and I've personally have had great success 
with this approach of organizing Milestones.


Comments?

Don

[1] http://www.twdata.org/dakine/roadmap/action.html
[2] http://www.edgewall.com/trac/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r350142 - /struts/action/trunk/src/java/org/apache/struts/action/DynaActionFormClass.java

[Laurie Harper]

Wendy Smoak wrote:

On 11/30/05, Martin Cooper <[EMAIL PROTECTED]> wrote:


There was a thread somewhere recently (I'm afraid I don't recall where)
about going in the opposite direction, for a good reason that I don't
recall. I'm hoping someone else here saw the same thing and has a better
memory. ;-) IIRC, the solution was to make the log instance transient and
access it through a getter.


Possibly...
http://www.nabble.com/-logging-Advice-on-static-instance-transient-Log-variables-t602568.html


Thanks for the link. If I understand the issue correctly, it would only 
be a problem is you had a logging implementation in the application 
classpath (WEB-INF/lib) but struts-action.jar in a shared classpath 
($TOMCAT_HOME/common/lib or similar).


If I recall correctly, putting Struts in a shared classpath like that is 
strongly discouraged and/or won't work anyway, so do we need to worry 
about this?


Or did I mis-understand the problem?

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CGLib DynaActioForm problem (was [VOTE] Confirm the Struts Action Library 1.3.0 release plan)

[Laurie Harper]

Niall Pemberton wrote:

On 11/30/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

Niall Pemberton wrote:

On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:

On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

Niall Pemberton wrote:

Also looked like the property types were the wrong way round for
indexed methods, so I also switched them.

Hmm, with that change, accessing a List property is broken. Without the
change, all my tests are working. You can deploy the exercises app with
the addition I just committed and see for yourself:
  http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do

I've rolled back your change and everything works fine again, including
indexed property access for arrays and lists. The unit test you added
passes either way.

I just refreshed and the JUnit test I wrote is now failing for me.

Its failing in gump as well
http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html

I've had problems with the maven build - when I've used build-all if a
sub-project test fails maven just carries on ignoring it and it
appears you get a successful build. Now I do the sub-projects
separately.

I'm wondering if thats what you used?

I was using 'maven test' without problem. It seems my checkout was
warped, though, because even though svn was telling me it was
up-to-date, after an 'svn update' I'm now seeing the failure.


This doesn't make any sense to me, unless you commit first and test after?


I'll look at it tomorrow and figure out what's wrong.


OK heres my take on what the issue is. The java bean specification
defines indexed properties in relation to arrays, so if you have
methods like...

  public String[] getFoo()  // simple read
  public void setFoo(String[] foo)  // simple write
  public String getFoo(int idx)  // indexed read
  public void setFoo(int idx, String foo)  // indexed write

...it will create an IndexedPropertyDescriptor instead of a
PropertyDescriptor for the Foo property. In previous JDK versions
(i.e. pre JDK 1.4 I believe) Sun was lenient about the simple
properties - it didn't care about the parameter/return type, so if you
defined your simple read/write methods with a java.util.List, it still
worked. However in JDK 1.4 they changed things, so that if the simple
read/write didn't return an array then it would still create an
IndexedPropertyDescriptor, but the getReadMethod/getWriteMethod return
null, effectively masking the simple read/write methods.

In DynaBeanInterceptor the indexed read/write methods it was creating
were incorrectly defined and so it wasn't recognizing those as indexed
properties (and your List worked). I believe my change fixed this
issue, and effectively masked the simple read/write methods for the
indexed property defined with a List, although I don't understand why
your test page didn't work because of this, since JSTL should have
been able to use the indexed read/write methods.

It would be interesting to see what happens with your test page with a
"regular" incorrectly defined indexed property, i.e.

  public List getFoo()
  public void setFoo(List foo)
  public String getFoo(int idx)
  public void setFoo(int idx, String foo)

OK I guess the question that stands out is, if I'm right on this how
come your test page worked with incorrectly defined indexed
properties. My guess is that JSTL is smart enough to handle simple
properties for arrays and Lists, but if thats true, the fact that your
page didn't work after my change means that its also too dumb to use
the indexed read/write methods.

Course I could have this wrong as this is all theory and I haven't put
any effort into actually proving it.

Niall


OK, so here's what's going on: JSTL always uses the simple read/write 
methods, never the indexed methods. As you surmise, in this case 
getReadMethod / getWriteMethod return null. Since JSTL (or at least the 
Jakarta Taglibs impl ;-) depends on the simple getter, this causes 
things to break.


So it looks like the solution is to either (a) not generate the indexed 
getter/setter at all, as was the case with the original code; or (b) 
only do so for array-typed properties; or (c) dynamically convert 
List-typed properties into array properties.


(c) isn't attractive; if I define a bean property of type List, I expect 
to be able to access it as such. It does seem worthwhile providing the 
indexed getter/setter for array-typed properties, so I think (b) would 
be the way to go.


I'll give it a try now and see it that does the trick.

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CGLib DynaActioForm problem (was [VOTE] Confirm the Struts Action Library 1.3.0 release plan)

[Laurie Harper]

Niall Pemberton wrote:

On 11/30/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

Niall Pemberton wrote:

On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:

On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

Niall Pemberton wrote:

Also looked like the property types were the wrong way round for
indexed methods, so I also switched them.

Hmm, with that change, accessing a List property is broken. Without the
change, all my tests are working. You can deploy the exercises app with
the addition I just committed and see for yourself:
  http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do

I've rolled back your change and everything works fine again, including
indexed property access for arrays and lists. The unit test you added
passes either way.

I just refreshed and the JUnit test I wrote is now failing for me.

Its failing in gump as well
http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html

I've had problems with the maven build - when I've used build-all if a
sub-project test fails maven just carries on ignoring it and it
appears you get a successful build. Now I do the sub-projects
separately.

I'm wondering if thats what you used?

I was using 'maven test' without problem. It seems my checkout was
warped, though, because even though svn was telling me it was
up-to-date, after an 'svn update' I'm now seeing the failure.


This doesn't make any sense to me, unless you commit first and test after?


Nope, I just somehow had a working copy that *looked* up to date but 
wasn't... Doesn't make any sense to me either, but I checked out a clean 
copy to make sure things were consistent so I should be fine now.





I'll look at it tomorrow and figure out what's wrong.


OK heres my take on what the issue is. The java bean specification
defines indexed properties in relation to arrays, so if you have
methods like...

  public String[] getFoo()  // simple read
  public void setFoo(String[] foo)  // simple write
  public String getFoo(int idx)  // indexed read
  public void setFoo(int idx, String foo)  // indexed write

...it will create an IndexedPropertyDescriptor instead of a
PropertyDescriptor for the Foo property. In previous JDK versions
(i.e. pre JDK 1.4 I believe) Sun was lenient about the simple
properties - it didn't care about the parameter/return type, so if you
defined your simple read/write methods with a java.util.List, it still
worked. However in JDK 1.4 they changed things, so that if the simple
read/write didn't return an array then it would still create an
IndexedPropertyDescriptor, but the getReadMethod/getWriteMethod return
null, effectively masking the simple read/write methods.

In DynaBeanInterceptor the indexed read/write methods it was creating
were incorrectly defined and so it wasn't recognizing those as indexed
properties (and your List worked). I believe my change fixed this
issue, and effectively masked the simple read/write methods for the
indexed property defined with a List, although I don't understand why
your test page didn't work because of this, since JSTL should have
been able to use the indexed read/write methods.

It would be interesting to see what happens with your test page with a
"regular" incorrectly defined indexed property, i.e.

  public List getFoo()
  public void setFoo(List foo)
  public String getFoo(int idx)
  public void setFoo(int idx, String foo)

OK I guess the question that stands out is, if I'm right on this how
come your test page worked with incorrectly defined indexed
properties. My guess is that JSTL is smart enough to handle simple
properties for arrays and Lists, but if thats true, the fact that your
page didn't work after my change means that its also too dumb to use
the indexed read/write methods.

Course I could have this wrong as this is all theory and I haven't put
any effort into actually proving it.

Niall


Right, that all makes sense. I'll add some tracing to see what JSTL is 
actually trying to invoke in each case, and do some testing w/ a 
non-dynamic form bean for comparison.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan

[Laurie Harper]

Niall Pemberton wrote:

On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:

On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

Niall Pemberton wrote:

Also looked like the property types were the wrong way round for
indexed methods, so I also switched them.

Hmm, with that change, accessing a List property is broken. Without the
change, all my tests are working. You can deploy the exercises app with
the addition I just committed and see for yourself:
  http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do

I've rolled back your change and everything works fine again, including
indexed property access for arrays and lists. The unit test you added
passes either way.

I just refreshed and the JUnit test I wrote is now failing for me.


Its failing in gump as well
http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html

I've had problems with the maven build - when I've used build-all if a
sub-project test fails maven just carries on ignoring it and it
appears you get a successful build. Now I do the sub-projects
separately.

I'm wondering if thats what you used?


I was using 'maven test' without problem. It seems my checkout was 
warped, though, because even though svn was telling me it was 
up-to-date, after an 'svn update' I'm now seeing the failure.


I'll look at it tomorrow and figure out what's wrong.

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan

[Laurie Harper]

Niall Pemberton wrote:

Also looked like the property types were the wrong way round for
indexed methods, so I also switched them.


Hmm, with that change, accessing a List property is broken. Without the 
change, all my tests are working. You can deploy the exercises app with 
the addition I just committed and see for yourself:


  http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do

I've rolled back your change and everything works fine again, including 
indexed property access for arrays and lists. The unit test you added 
passes either way.


If you think there's a scenario not covered by the exercises page that 
would be broken with the original code let me know and I'll look into it 
further.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 36794] - Enhance DynaActionForm and sub-classes to allow normal property access in JSPs

[Laurie Harper]

Wendy Smoak wrote:

On 11/26/05, Laurie Harper <[EMAIL PROTECTED]> wrote:


Ted, where do I edit the release notes for 1.3.0? The only likely
candidate looked to be

   action/xdocs/userGuide/release-notes.xml

but that looks like it's the 1.2.8 release notes... Are 1.3.0 release
notes being aggregated somewhere else?


That's the right page, it has:
   
and
   Release Notes (since 1.2.8)

(Ther rest of the references to 1.2.7 need to be changed to 1.2.8. 
I'll catch that after you make your changes, unless you want to do

it.)


Doh, sorry, I was thrown off by a combination of the lack of a 
release-notes-1.2.8.xml and inattentive reading... I've fixed the one 
remaining 1.2.7 reference and added the stuff I needed to.


L.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [shale?] mimicking wildcard action mapping paths

[Laurie Harper]

That sounds like it might provide a much less hackish solution; I'll 
look into that.


Thanks,

L.

Sean Schofield wrote:

Yould can probably implement your own NavigationHandler.  Check out
the DialogNavigationHandler in Shale.  It implements custom navigation
handling on top of the JSF standard.  You could try something similar.

sean

On 11/28/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

Craig McClanahan wrote:

On 11/26/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

I suspect that Shale doesn't provide anything over-and-above the
standard JSF navigation management in this area, in which case this may
be more of a general JSF question:

Well, it does offer above-and-beyond navigation support inside a dialog, but
that doesn't really address your question.

I use wildcard action mapping paths extensively, which of course

continues to work unchanged with struts-faces, but I'm wondering how I'd
achieve the same goals with Shale.

Here's what I have using Struts:

- I have action mappings like

 

- My actions parse the expanded 'parameter' value into a map:

 {'project' -> 'foo', 'release' -> 'bar'}

   which is used to determine the data to load for the view

- My 'forward' declarations use the matches (e.g. {1}) to
   specify the view to forward to,

 

You can indeed use wildcards in from-view-id (or from-outcome) clauses in
the navigation rules ... but that doesn't deal with the parameter
substitution you are proposing.

Good to know that wildcards can be used like that. I guess that would
get me part way there...


I'm still not sure how I get a backing bean setup with data supplied as

request parameters, but I think I should be able to figure that out
easily enough. The bit I have no idea how to solve is the use of path-
extra-info--based URLs...


JSF prefers that you forget such things as URLs and request parameters
actually exist :-).  What you are passing around is typically model data, so
the preferred solution is to use request or session scope attributes
(depending on whether you're doing a redirect), or properties of such a
request or session scope bean.

That's all very well, but doesn't fit my requirements very well ;-)
Specifically, that resources be directly addressable by URL and
bookmarkable.

Using wildcards in the from-view-id as above, and implementing the URL
path processing in a filter that effectively added the extracted data as
  additional request parameters, I should then be able to do something
like this, right?

 
 /Projects/*/Releases/*
 
 edit
 
 /Projects/ReleaseEdit.jsp?
 project=#{param[project]&
 release=#{param[release]}
 
 
 
 

I'd lose having the URL patterns localized to a single place, though.

L.


-
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: [shale?] mimicking wildcard action mapping paths

[Laurie Harper]

Craig McClanahan wrote:

On 11/26/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

I suspect that Shale doesn't provide anything over-and-above the
standard JSF navigation management in this area, in which case this may
be more of a general JSF question:


Well, it does offer above-and-beyond navigation support inside a dialog, but
that doesn't really address your question.

I use wildcard action mapping paths extensively, which of course

continues to work unchanged with struts-faces, but I'm wondering how I'd
achieve the same goals with Shale.

Here's what I have using Struts:

- I have action mappings like

 

- My actions parse the expanded 'parameter' value into a map:

 {'project' -> 'foo', 'release' -> 'bar'}

   which is used to determine the data to load for the view

- My 'forward' declarations use the matches (e.g. {1}) to
   specify the view to forward to,

 


You can indeed use wildcards in from-view-id (or from-outcome) clauses in
the navigation rules ... but that doesn't deal with the parameter
substitution you are proposing.


Good to know that wildcards can be used like that. I guess that would 
get me part way there...



I'm still not sure how I get a backing bean setup with data supplied as

request parameters, but I think I should be able to figure that out
easily enough. The bit I have no idea how to solve is the use of path-
extra-info--based URLs...



JSF prefers that you forget such things as URLs and request parameters
actually exist :-).  What you are passing around is typically model data, so
the preferred solution is to use request or session scope attributes
(depending on whether you're doing a redirect), or properties of such a
request or session scope bean.


That's all very well, but doesn't fit my requirements very well ;-) 
Specifically, that resources be directly addressable by URL and 
bookmarkable.


Using wildcards in the from-view-id as above, and implementing the URL 
path processing in a filter that effectively added the extracted data as 
 additional request parameters, I should then be able to do something 
like this, right?



/Projects/*/Releases/*

edit

/Projects/ReleaseEdit.jsp?
project=#{param[project]&
release=#{param[release]}





I'd lose having the URL patterns localized to a single place, though.

L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[shale?] mimicking wildcard action mapping paths

[Laurie Harper]

I suspect that Shale doesn't provide anything over-and-above the 
standard JSF navigation management in this area, in which case this may 
be more of a general JSF question:


I use wildcard action mapping paths extensively, which of course 
continues to work unchanged with struts-faces, but I'm wondering how I'd 
achieve the same goals with Shale.


Here's what I have using Struts:

- I have action mappings like



- My actions parse the expanded 'parameter' value into a map:

{'project' -> 'foo', 'release' -> 'bar'}

  which is used to determine the data to load for the view

- My 'forward' declarations use the matches (e.g. {1}) to
  specify the view to forward to,



Using Shale (or JSF in general), I'm not sure how to achieve the same 
thing. Ideally, I'd be able to do something like this:



/Projects/*/Releases/*

edit

/Projects/ReleaseEdit.jsp?project={1}&release={2}





or better yet, have the to-view-id refernce a logical path the way the 
Struts 'forward' does -- that's the bit where I thought maybe Shale 
might be able to help.


I'm still not sure how I get a backing bean setup with data supplied as 
request parameters, but I think I should be able to figure that out 
easily enough. The bit I have no idea how to solve is the use of path- 
extra-info--based URLs...


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan

[Laurie Harper]

Niall Pemberton wrote:

project rather than core. At the moment I'm -0 on this feature because it
doesn't have any JUnit tests - if tests are added I'd change that to a +0!


Niall, are you comfortable with just a test page in the exercises app? I 
have that almost ready to commit; I just have to figure out what I have 
to do to have JSTL expressions evaluated correctly in all supported 
levels of JSP release.


I'll be happy to add JUnit tests as well if you (or anyone) really wants 
them ;-) but it might take a little longer to get to.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DO NOT REPLY [Bug 36794] - Enhance DynaActionForm and sub-classes to allow normal property access in JSPs

[Laurie Harper]

Ted, where do I edit the release notes for 1.3.0? The only likely 
candidate looked to be


  action/xdocs/userGuide/release-notes.xml

but that looks like it's the 1.2.8 release notes... Are 1.3.0 release 
notes being aggregated somewhere else?


L.

[EMAIL PROTECTED] wrote:

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36794





--- Additional Comments From [EMAIL PROTECTED]  2005-11-22 13:35 ---
Please also integrate the sample JSP and Action with the Exercise application or
Cookbook, update the release notes, and extend the DynaActionForm section of the
users guide (4.3.1).





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]