date:20060427

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by tmjee:
http://wiki.apache.org/struts/RoughSpots

--
  * [jcarreira] You had me until the abstract class bit... Does it have to 
be abstract? Also, this limits testability in not-ok-ways... 
  * [crazybob] It only has to be abstract if you want your action to be 
able to call methods on the mixin without casting. If it doesn't need to call 
those methods, there's no need for your action to explicitly implement that 
interface. You could also say `((ValidationAware) this).addActionError()`. I 
personally don't mind making the action abstract. In IntelliJ, you just make a 
mock class that extends your action and it will automatically generate stubs 
for the methods.
  * [plightbo] As mentioned earlier, you might be able to do this by using 
the value stack. For example, you could stick in a single "ValidationSupport" 
object at the bottom of the stack and then all classes would add error messages 
there. By adding a simple *Aware interface, actions could get a handle to that 
for adding error messages.
- 
- * [jcarreira] Very nice idea... +1 ... We already do something like that. 
There's always a default TextProvider pushed onto the bottom of the stack for 
getting default texts... makes localized texts work with Sitemesh, for 
instance, when you're not hitting an action. Of course, that will be a problem 
when we're not using ThreadLocals. 
+ * [jcarreira] Very nice idea... +1 ... We already do something like that. 
There's always a default TextProvider pushed onto the bottom of the stack for 
getting default texts... makes localized texts work with Sitemesh, for 
instance, when you're not hitting an action. Of course, that will be a problem 
when we're not using ThreadLocals.
+ * [tm_jee] What about keeping ActionSupport but instead have an 
AbstractActionSupport which ActionSupport extends off which consisting of 
getter/setters for the plugable strategy (like setValidatable(...) 
setValidationAware(...) setTextProvider(...) etc). There will be a default for 
those if none is set. We could then wired them in through Spring since Sprinc 
is now the recommended IOC container.
+  
  
1. [molitor]Extends support on actions in xml (Configuration Inheritance). 
Occasionally I want to utilize an existing action but only change one 
parameter. It would be nice to do something as simple as.{{{
 

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

[Struts Wiki] Update of "RoughSpots" by tmjee

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by tmjee:
http://wiki.apache.org/struts/RoughSpots

--
  }}}I'd prefer using this approach instead of having the xmlAction 
chain to another.
  
1. [molitor] Modular Ant Build, I've started working on this using the 
build files that Jason supplied (which were forwarded on to me). Allows the 
project to build in whole or in part with seperate build files that extend a 
set of common/parent build files. Should parallel the maven build.
+  [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get 
familiar with Maven and would like to keep an alternate optiona available. :-)
  
  == What JDK Version? ==
  

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

[Struts Wiki] Update of "RoughSpots" by tmjee

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by tmjee:
http://wiki.apache.org/struts/RoughSpots

--
  
 xmlAddPerson.jsp
  }}}I'd prefer using this approach instead of having the xmlAction 
chain to another.
+  * [tm_jee] Sounds cool. It would probably be an overkill to extend this 
idea into the interceptor as well, wouldn't it.
  
1. [molitor] Modular Ant Build, I've started working on this using the 
build files that Jason supplied (which were forwarded on to me). Allows the 
project to build in whole or in part with seperate build files that extend a 
set of common/parent build files. Should parallel the maven build.
-  [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to get 
familiar with Maven and would like to keep an alternate optiona available. :-)
+  * [tm_jee] +1 Jason's Ant Build is impressive, I'll need some time to 
get familiar with Maven and would like to keep an alternate optiona available. 
:-)
  
  == What JDK Version? ==
  

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

Re: Proposal for change

2006-04-27 Thread Jonathan Revusky


Dakota Jack wrote:

Doesn't this kind of talk sound goofy to you all?  Isn't this reference to
the Apache Way sort of like a secret handshake and a silly hat? 


It's all that, yes, but it's also not very honest, I'd say.

You see, the various scripture on the so-called "Apache Way" claims that 
the ASF is run as a "meritocracy". What you see here is that the Struts 
committers, after years of not achieving much, have invited in the 
Webwork people with the intention of relabelling Webwork as Struts 
Action 2 (when the existing Struts codebase is Struts Action 1). They 
tacitly accept that the Webwork people ran the better project 
technically, did the better work.


Well, once you accept that the other people did the better work, and you 
have a meritocracy, then those other people, who have more merit, they 
run the show.


The logic of this looks unassailble to me.

So, by what basic principle does the existing Struts PMC remain in 
control of the project when they accept that the other people did better 
work?


The only principle I see is the principle of incumbency or tenure.

When people who did inferior work remain the managers of a project (and 
ostensibly manage the people who did the better work) and this is by 
virtue of incumbency or tenure, you don't have a meritocracy.


So, actually, seriously applying the principles outlined about 
meritocracy would necessarily imply an extreme shake-up in the Struts 
project. However, in a typically ass backwards way, the "Apache Way" 
stuff is being used as a rhetorical instrument to quell dissent -- 
"don't rock the boat". As another example of ass backwards rhetoric, in 
his "This has gone too far" post, Don Brown implies that the reason for 
a lack of forward progress is the presence of that discussion. But that 
is 180º away. That and other such discussions came about precisely 
because of the lack of forward progress. The causality is in completely 
the other direction.


Of course, it's clear why there's an attempt to shut down any discussion 
that casts doubt on the way in which certain people are club members and 
others are not. It has nothing to do with any "Apache Way". It can't be 
openly discussed because, in reality, the incumbent managers of the 
project do not have a leg to stand on. If they accepted the basic logic 
of a meritocracy, Don and Ted and the rest would have to just resign and 
let new people in.


Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker blog, http://freemarker.blogspot.com/









Let's say
what the Struts Way is.  It is not, I would strongly suggest even slightly
related to the Apache Way.  I am also strongly considering just never coming
back here.  I am getting just to sick of the plain and unvarinshed stupidity
on this list.

On 4/25/06, Martin Cooper <[EMAIL PROTECTED]> wrote:


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


On Tue, April 25, 2006 2:22 pm, Paul Speed said:



Frank W. Zammetti wrote:



You are of course right about this.  But, much like taking the ideas
about
inventory control and order processing and such from Dell and


starting


your own business is possible, the likelihood that you would get
anything
but a small fraction of the attention and business that Dell gets is
slim
to none.


Not to sidle in where I don't really belong but perhaps this last
sentence exemplifies the disconnect with "getting it"?  If one wanted


to


take the code from an apache project and do something else with it


then


all they care about is the something else they want to do.  It isn't
really a "business"... the code exists for the code's sake.


You aren't chiming in where you don't belong... if your interested, you
belong, at least as far as I'm concerned :)

I think there is definitely something to your point, and the analogy may
have been a bit flawed.  However...

I don't think it is accurate to think that ego doesn't play a part in


just


about everything that just about everyone does.  We all want to see our
work benefit others.  For most of us I believe its because we genuinely
like the feeling we get when someone writes us and says "hey, your code
really helped me, thank you!".  I know speaking for myself, it makes my
day when I get those eMails!  Part of it is simply the ego stroke of
someone essentially saying your work is worth something, but I don't
believe that is the big factor for most people.  I know it isn't for me,
and I don't think it is for the Struts team.  I think the thank you note
means as much to them as it does me.

If you agree with that, then the idea of forking the code and doing it
with the belief that you aren't going to reach a wide audience because


the


Apache version continues to be what people go to, is not appealing.  In
that regard, if we substitute ego for money in the analogy, I think it
still works (although just saying ego is dangerous because as I tried to
illustrate above, I think there is good ego and bad

[Struts Wiki] Update of "RoughSpots" by tmjee

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by tmjee:
http://wiki.apache.org/struts/RoughSpots

--
  * [jcarreira] A new instance per action configuration, right? Not 
per-invocation... 
  * [crazybob] Last I tested it was per invocation (I remember because it 
surprised me). This is actually a non-issue. We'll create a custom 
`ConfigurationProvider` for Struts which won't have this problem.
  * [plightbo] Agreed, by abstracting most configuration out, we can 
control the lifecycle. I think the lifecycle should be either once per 
interceptor or once per invocation. Currently the implementation is too 
cumbersome (once per unique action configuration).
+ * [tm_jee] I'd prefer to keep them as a separate optional implementable 
interface as Bob advised, such that Interceptor interface implementor are not 
required to implement them, and for the minority who needs them, its there.
  
1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods 
doesn't make things simpler. It reduces flexibility. We can't return a 
different result. You can't handle exceptions cleanly. The actual interceptor 
class doesn't appear in the stack trace (we see `AroundInterceptor` over and 
over).
  
@@ -99, +100 @@

to write applications that work for portlets too?  I would hope that we 
all work towards a world where
direct access to the underlying servlet API objects is considered an 
anti-pattern.
  * [crazybob] Another good point.
+ 
  
1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would 
be a better name.
  
@@ -111, +113 @@

  * [crazybob] Does "specified" == "documented"? Can you elaborate on 
"easily knowing when you're done" and why we can't address that use case with 
one interface? We should expose the user to one interface: `Invocation`. We can 
have as many objects as we like when it comes to the internal implementation.
  * [plightbo] Big +1. I would add the ValueStack to this list as well. 
Let's have one object for each invocation, and also make "sub invocations" 
(chaining or ww:action calls) a first class citizen through child/parent 
invocation relationships.
  * [jcarreira] Let's have an interactive design session on this... I'm not 
sure it's as easy as you think to merge them all into one (although behind one 
interface should be doable).
+ * [tm_jee] Sorry, I don't get this bit. :-P  We could just expose 
ActionInvocation. ActionProxy could be obtained from ActionInvocation. Or maybe 
just expose ActionProxy's method in ActionInvocation, but actually its just 
delegating to ActionProxy. Did I miss something?
  
1. Should `ActionInvocation.getResult()` recurse over chain results? Maybe 
we should have two methods? `getResult()` and `getFinalResult()`. Is there a 
good use case for this?
  
@@ -129, +132 @@

  * [mrdon] I dunno, are you planning to make protected getters/setters for 
every field?  I've found protected fields to be invaluable when extending 
frameworks (again, subscribing to the believe we should let the user do what 
they want and not artifically restrict them).  I do wish you could declare the 
fields _only_ available to subclasses and not to the whole package.
  * [crazybob] Absolutely, methods instead of fields. Methods enable us to 
hook access if need be, change the underlying implementation, manage thread 
safety, protect our own code against unexpected conditions/states, etc. Fields 
are OK within a package, but when it comes to public APIs, better safe than 
sorry a year from now.
  * [jcarreira] Oops, I was translating "fields" -> "properties" and 
thinking of getters and setters.
+ * [tm_jee] I am kindof thinking in the same line as Don.
  
1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is 
better.
  
@@ -140, +144 @@

  * [plightbo] The name doesn't bother me, but the implementation is far 
too complex. I would propose we cut it down from all the crazy 
package/interface/model-driven stuff we have now to a simple i18n RB loading 
approach that uses 0 or more global bundles as well as bundles associated with 
the _view_ (NOT the action, since that never made much sense).
  * [mrdon] I'd like to see this re-evaluated as well.   For one, I want to 
make it easier to provide an impl that gets messages from a Struts bundle, 
which really isn't possible now.
  * [jcarreira] +1 to simplifying. We started with lots of separate 
resource bundles for per-action texts, but we're moving to one resource bundle 
per module. It's too much hassle.
+ * [tm_jee] I like the feature WebWork has that allows resource bundle to 
be overriden at different levels through inheritance hierarchy, package 
hierarchy and a global level. If possible, please keep them. :-)

Re: Proposal for change

2006-04-27 Thread Kimani Darisha

z...

On 4/27/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote:
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> blah, blah, blah, bla blah, blah, blah, bla blah, blah, blah, bla
> Now I demand you to answer my blah blah!!

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

[Struts Wiki] Update of "RoughSpots" by tmjee

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by tmjee:
http://wiki.apache.org/struts/RoughSpots

--
1. Remove `destroy()` and `init()` from `Interceptor`. They don't make much 
sense until the interceptor lifecycle is specified (see next item). I've never 
needed them, yet it's a pain to implement empty methods every time I implement 
an interceptor. Users can use the constructor/finalizer or we can create 
additional lifecycle interfaces.
  
  * [plightbo] I don't really care. This ties more in to the next item...
+ * [tm_jee] I'd prefer to keep them as a separate optional implementable 
interface as Bob advised, such that Interceptor interface implementor are not 
required to implement them, and for the minority who needs them, its there.
  
1. Specify `Interceptor` lifecycle. Right now if we apply an interceptor to 
a single action, we get a new instance every time. If we define an interceptor 
in a stack, the same instance gets reused.
  
  * [jcarreira] A new instance per action configuration, right? Not 
per-invocation... 
  * [crazybob] Last I tested it was per invocation (I remember because it 
surprised me). This is actually a non-issue. We'll create a custom 
`ConfigurationProvider` for Struts which won't have this problem.
  * [plightbo] Agreed, by abstracting most configuration out, we can 
control the lifecycle. I think the lifecycle should be either once per 
interceptor or once per invocation. Currently the implementation is too 
cumbersome (once per unique action configuration).
- * [tm_jee] I'd prefer to keep them as a separate optional implementable 
interface as Bob advised, such that Interceptor interface implementor are not 
required to implement them, and for the minority who needs them, its there.
+ 
  
1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods 
doesn't make things simpler. It reduces flexibility. We can't return a 
different result. You can't handle exceptions cleanly. The actual interceptor 
class doesn't appear in the stack trace (we see `AroundInterceptor` over and 
over).
  

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

svn commit: r397545 - /incubator/webwork2/action/src/main/resources/template/ajax/form-close.ftl

Author: tmjee
Date: Thu Apr 27 06:56:05 2006
New Revision: 397545

URL: http://svn.apache.org/viewcvs?rev=397545&view=rev
Log:
make auto-select upon form submit for optiontransferselect and
updownselect work in ajax theme


Modified:
incubator/webwork2/action/src/main/resources/template/ajax/form-close.ftl

Modified: 
incubator/webwork2/action/src/main/resources/template/ajax/form-close.ftl
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/action/src/main/resources/template/ajax/form-close.ftl?rev=397545&r1=397544&r2=397545&view=diff
==
--- incubator/webwork2/action/src/main/resources/template/ajax/form-close.ftl 
(original)
+++ incubator/webwork2/action/src/main/resources/template/ajax/form-close.ftl 
Thu Apr 27 06:56:05 2006
@@ -13,11 +13,11 @@
dojo.event.connect(containingForm, "onsubmit", 
function(evt) {
var selectObj = 
document.getElementById("${selectObjectId}");
-   selectAllOptions(selectObj);
-   selectUnselectMatchingOptions(selectObj, null, 
"unselect", false, "key");
<#if 
parameters.optiontransferselectIds.get(selectObjectId)?exists>
<#assign selectTagHeaderKey = 
parameters.optiontransferselectIds.get(selectObjectId)/>
-   
selectUnselectMatchingOptions(selectObj, "${selectTagHeaderKey}", "unselect", 
false, "key");
+   selectAllOptionsExceptSome(selectObj, 
"key", "${selectTagHeaderKey}");
+   <#else>
+   selectAllOptionsExceptSome(selectObj, 
"key", "");

});

@@ -29,11 +29,11 @@
dojo.event.connect(containingForm, "onsubmit", 
function(evt) {
var selectObj = 
document.getElementById("${selectObjId}");
-   selectAllOptions(selectObj);
-   selectUnselectMatchingOptions(selectObj, null, 
"unselect", false, "key");
<#if 
parameters.optiontransferselectDoubleIds.get(selectObjId)?exists>
<#assign selectTagHeaderKey = 
parameters.optiontransferselectDoubleIds.get(selectObjId)/>
-   
selectUnselectMatchingOptions(selectObj, "${selectTagHeaderKey}", "unselect", 
false, "key");
+   selectAllOptionsExceptSome(selectObj, 
"key", "${selectTagHeaderKey}");
+   <#else>
+   selectAllOptionsExceptSome(selectObj, 
"key", "");

});

@@ -45,17 +45,17 @@
submission
 -->
 <#if (parameters.updownselectIds?if_exists?size > 0)>
-var containingForm = document.getElementById("${parameters.id}");
+   var containingForm = document.getElementById("${parameters.id}");
<#assign tmpIds = parameters.updownselectIds.keySet() />
<#list tmpIds as tmpId>
dojo.event.connect(containingForm, "onsubmit", 
function(evt) {
-   var selectObj = 
document.getElementById("${tmpId}");
-   selectAllOptions(selectObj);
-   selectUnselectMatchingOptions(selectObj, null, 
"unselect", false, "key");
+   var updownselectObj = 
document.getElementById("${tmpId}");
<#if 
parameters.updownselectIds.get(tmpId)?exists>
<#assign tmpHeaderKey = 
parameters.updownselectIds.get(tmpId) />
-   
selectUnselectMatchingOptions(selectObj, "${tmpHeaderKey}", "unselect", false, 
"key");
+   
selectAllOptionsExceptSome(updownselectObj, "key", "${tmpHeaderKey}");
+   <#else>
+   
selectAllOptionsExceptSome(updownselectObj, "key", "");

});

@@ -63,6 +63,11 @@
 
 
 
+<#-- 
+ Code that will add javascript needed for tooltips
+--><#t/>
+   <#lt/>
+   <#lt/>dojo.require("dojo.widget.html.Tooltip");dojo.require("dojo.fx.html");
 
 
 



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

[Struts Wiki] Update of "FrontPage" by JamesMitchell

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by JamesMitchell:
http://wiki.apache.org/struts/FrontPage

The comment on the change is:
JavaOne baby!!

--
   * StrutsFunStuff -- Miscellaneous, generally off-topic pages
   * StrutsWikiTips -- Tips to more effectively use this wiki
   * StrutsJobJar -- Help wanted
+  * StrutsJavaOne2006 -- Struts specific hangouts/parties and anything else 
related to Struts at JavaOne
  

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

[Struts Wiki] Update of "StrutsJavaOne2006" by JamesMitchell

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by JamesMitchell:
http://wiki.apache.org/struts/StrutsJavaOne2006

New page:
What are you going to attend at !JavaOne this year?

Current list of Struts happenings and interests.  Please add your name to 
sessions you think you'd like to see.  If the session is not listed, please add 
it.

||'''Tuesday (Apr 16)'''|| || || ||
||Times || Event || Location || Who plans to attend? ||
|| 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || Halls 
B & C|| JM ||
||'''Wednesday (Apr 17)'''|| || || ||
|| 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || || ||
|| 5:30 PM - 6:30 PM || Struts BOF || || DB, JM||
|| 7:30 PM - 8:30 PM || !MyFaces BOF || || JM ||
||'''Thursday (Apr 18)'''|| || || ||
||'''Friday (Apr 19)'''|| || || ||

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

svn commit: r397563 - /struts/action/trunk/taglib/README.txt

Author: jmitchell
Date: Thu Apr 27 08:14:55 2006
New Revision: 397563

URL: http://svn.apache.org/viewcvs?rev=397563&view=rev
Log:
remove old maven 1 instructions

Removed:
struts/action/trunk/taglib/README.txt


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

[Struts Wiki] Update of "StrutsJavaOne2006" by DonBrown

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by DonBrown:
http://wiki.apache.org/struts/StrutsJavaOne2006

--
  || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || 
Halls B & C|| JM ||
  ||'''Wednesday (Apr 17)'''|| || || ||
  || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || || ||
- || 5:30 PM - 6:30 PM || Struts BOF || || DB, JM||
+ || 5:30 PM - 6:30 PM || Struts BOF || Pavilion || DB, JM||
  || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM ||
  ||'''Thursday (Apr 18)'''|| || || ||
  ||'''Friday (Apr 19)'''|| || || ||

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

Linking SVN to JIRA

2006-04-27 Thread Greg Reddin

I'm getting ready to make some commits and I'd like to link them to  
JIRA tickets.  Is there a way to format the commit message so that  
JIRA or something will automatically associate the commit with the  
ticket?  I've seen this discussed before but I'm not sure if I've  
seen the specifics for how to do it.  Sorry if it's widely known and  
I somehow missed it.


Greg


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

RE: Linking SVN to JIRA

2006-04-27 Thread Chandra.Ravinithala

I could find this following link; hope this helps.

http://mail-archives.apache.org/mod_mbox/forrest-dev/200601.mbox/%3C2006
[EMAIL PROTECTED]

 

-Original Message-
From: Greg Reddin [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 27, 2006 8:49 PM
To: Struts Developers List
Subject: Linking SVN to JIRA

I'm getting ready to make some commits and I'd like to link them to JIRA
tickets.  Is there a way to format the commit message so that JIRA or
something will automatically associate the commit with the ticket?  I've
seen this discussed before but I'm not sure if I've seen the specifics
for how to do it.  Sorry if it's widely known and I somehow missed it.

Greg


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

[Struts Wiki] Update of "StrutsJavaOne2006" by GregReddin

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by GregReddin:
http://wiki.apache.org/struts/StrutsJavaOne2006

--
  
  ||'''Tuesday (Apr 16)'''|| || || ||
  ||Times || Event || Location || Who plans to attend? ||
- || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || 
Halls B & C|| JM ||
+ || 8:30 AM - 10:30 AM || Sun General Session: Making Java Work for You || 
Halls B & C|| JM, GR ||
  ||'''Wednesday (Apr 17)'''|| || || ||
- || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || || ||
+ || 2:45 PM - 3:45 PM || TS-3682 -- What's Going On in Struts Ti? || ||GR ||
- || 5:30 PM - 6:30 PM || Struts BOF || Pavilion || DB, JM||
+ || 5:30 PM - 6:30 PM || Struts BOF || Pavilion || DB, JM, GR||
- || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM ||
+ || 7:30 PM - 8:30 PM || !MyFaces BOF || || JM, GR ||
  ||'''Thursday (Apr 18)'''|| || || ||
  ||'''Friday (Apr 19)'''|| || || ||
  

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

[Struts Wiki] Update of "RoughSpots" by JasonCarreira

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by JasonCarreira:
http://wiki.apache.org/struts/RoughSpots

--
  * [jcarreira] We've implemented this at work with WebWork fileupload + 
DWR + a class that looks at the file as it's uploading to see how big it is on 
disk
  * [frankz] Just an opinion, but this seems to me too specific a use case 
for a framework to encapsulate.  I think having an example showing how to do 
it, perhaps what jcarreira has done at work, would be great, but I for one 
wouldn't like the framework offering this out of the box... I think it is 
possible for a framework to be able to do TOO much!
  * [tm_jee] I think this is pretty use case specific as well, but a 
progress monitor ui component would be nice. 
+ * [jcarreira] If we agree that supporting file uploads out of the box is 
important, then this is just a nice feature for that support to let the user 
know how much of the file has been uploaded, etc.
  
1. Better error checking for UI tags. The freemarker error message, while 
great for freemarker users, look like gibberish. People should not be forced to 
learn freemarker. So in such cases, the tags themselves should check the 
parameters and report back sane messages, even if that check is duplicated in 
the templates
  
@@ -280, +281 @@

1. Specify and simplify Interceptor scope. Currently, you have an 
Interceptor that calls actionInvocation.invoke() and then returns a different 
result than actionInvocation.invoke() returns, the actionInvocation.invoke() 
result will be used anyway. This is confusing and muddies the meaning of the 
Interceptor API, which IMHO should simply wrap the action not the action all 
the way through to the end of the result. The reason it's set up the way it is, 
as I understand it, is so that Interceptors can clean up resources like 
connections after the result is returned. However, I wonder if we can implement 
a request based object that can take care of such resources and destroy them at 
the end of the request rather than using Interceptors in this way.
   * [crazybob] That was really surprising and confusing to me at first, 
too. I thought it would have been more intuitive for the result to run after 
all the interceptors returned. I'm not sure whether we should change it or not. 
I like the idea of interceptors being able to clean up after results a lot more 
than I like the idea of an interceptor being able to return a different result.
   * [Gabe] It is an advantage for Interceptors to be able to clean up at 
the end of a request, but it isn't great how they do that either. Take for 
example an action chain. If you have a create connection Interceptor 
surrounding each of the chained actions, you will open two connections, which 
besides being wasteful could cause problems with other resource types. I wonder 
if we can create some sort of request scoped ResourceManager class that can 
allow Interceptors to create resources or access them if they exist and specify 
how they should be destroyed at the end of the request. Thus in the connection 
case, the Interceptor could check if the resource manager had one and if not 
create it and add it to the resource manager for other objects to use. (Another 
option of course is an inversion of control approach)
+ * [jcarreira] Interceptors can still change the result... Implement 
PreResultListener and in your callback, change the resultCode and voila! The 
result executed will be changed. The PreResultListener interface lets you 
register your interceptor to get a callback after the action and before the 
result is executed. Oh, and on the ConnectionInterceptor -> It's just like AOP. 
You have to check if it's been done already and know not to create a new one or 
close it on the way out. I do this all the time in AOP interceptors, so why 
should this be different? Personally, I'd rather use the same connection across 
all of the actions in a chain than clean it up after each one and use a new one 
per action. For request scoped resources, take a look at Spring's scoped 
components. I'm using them at work and they work pretty well (a few issues I'm 
working through with them notwithstanding). 
  
  == Tim's Issues ==
  I'm new around here, so be nice ;)  I probably have a lot less WW experience 
than most, so I apologize in advance if I'm flat out wrong about some of the 
things here.
@@ -288, +290 @@

  
  * [crazybob] I prefer an injection-based approach. You can use the 
`ScopeInterceptor` to pull an object off the session and pass it to your 
action. Or you can use Spring to inject session-scoped objects into your action 
(though I would avoid Spring personally).
  
+ * [jcarreira] I can attest that the Spring scoped components work well 
with WebWork. It's what we use at

svn commit: r397572 - /incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/FilterDispatcher.java

Author: tmjee
Date: Thu Apr 27 08:43:30 2006
New Revision: 397572

URL: http://svn.apache.org/viewcvs?rev=397572&view=rev
Log:
WW-1278


Modified:

incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/FilterDispatcher.java

Modified: 
incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/FilterDispatcher.java
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/FilterDispatcher.java?rev=397572&r1=397571&r2=397572&view=diff
==
--- 
incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/FilterDispatcher.java
 (original)
+++ 
incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/FilterDispatcher.java
 Thu Apr 27 08:43:30 2006
@@ -163,10 +163,20 @@
 public void doFilter(ServletRequest req, ServletResponse res, FilterChain 
chain) throws IOException, ServletException {
 HttpServletRequest request = (HttpServletRequest) req;
 HttpServletResponse response = (HttpServletResponse) res;
+ServletContext servletContext = filterConfig.getServletContext();
 
 // prepare the request no matter what - this ensures that the proper 
character encoding
 // is used before invoking the mapper (see WW-9127)
 DispatcherUtils du = DispatcherUtils.getInstance();
+try {
+   // Wrap request first, just in case it is multipart/form-data 
+   // parameters might not be accessible through before encoding 
(ww-1278)
+request = du.wrapRequest(request, servletContext);
+} catch (IOException e) {
+String message = "Could not wrap servlet request with 
MultipartRequestWrapper!";
+LOG.error(message, e);
+throw new ServletException(message, e);
+}
 du.prepare(request, response);
 
 ActionMapper mapper = ActionMapperFactory.getMapper();
@@ -194,19 +204,11 @@
 
 
 Object o = null;
-ServletContext servletContext = filterConfig.getServletContext();
 try {
 
 setupContainer(request);
 o = beforeActionInvocation(request, servletContext);
-
-try {
-request = du.wrapRequest(request, servletContext);
-} catch (IOException e) {
-String message = "Could not wrap servlet request with 
MultipartRequestWrapper!";
-LOG.error(message, e);
-throw new ServletException(message, e);
-}
+
 du.serviceAction(request, response, servletContext, mapping);
 } finally {
 afterActionInvocation(request, servletContext, o);



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

[jira] Resolved: (STR-2729) [Standalone Tiles] Refactor Taglib

2006-04-27 Thread Greg Reddin (JIRA)

 [ http://issues.apache.org/struts/browse/STR-2729?page=all ]
 
Greg Reddin resolved STR-2729:
--

Resolution: Fixed
 Assign To: Greg Reddin  (was: Struts Developer Mailing List)

Taglib was refactored a month or so back.  I must've forgotten to close the 
ticket.

> [Standalone Tiles] Refactor Taglib
> --
>
>  Key: STR-2729
>  URL: http://issues.apache.org/struts/browse/STR-2729
>  Project: Struts Action 1
> Type: Improvement

>   Components: Sandbox
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
> Reporter: Greg Reddin
> Assignee: Greg Reddin
> Priority: Minor

>
> The API refactoring broke the taglib. It was patched back together enough to 
> make it compile again, and 
> so far it actually works. The core functionality needs to be extracted from 
> the taglib and the codebase 
> needs to be further refined to provide those features. In the process test 
> cases need to be developed to 
> verify the functionality. (How do you test a taglib?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Commented: (WW-1278) Prefix failed when Multipart form is submited

2006-04-27 Thread tm_jee (JIRA)

[ http://issues.apache.org/struts/browse/WW-1278?page=comments#action_37211 
] 

tm_jee commented on WW-1278:


Hi Rainer, 

I've commited the fix into svn when i was working on of my sample app that 
needs this. Kindly review, if its and resolve this issue if appropriate. Thx  
:-)


> Prefix failed when Multipart form is submited
> -
>
>  Key: WW-1278
>  URL: http://issues.apache.org/struts/browse/WW-1278
>  Project: Struts Action 2
> Type: Bug

> Versions: WW 2.2.2
> Reporter: tm_jee
> Assignee: Rainer Hermanns
>  Fix For: 2.0

>
> Prefix failed when Multipart form is submited
> see http://forums.opensymphony.com/thread.jspa?threadID=23756&tstart=0

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

svn commit: r397574 - /incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/mapper/DefaultActionMapper.java

Author: tmjee
Date: Thu Apr 27 08:47:13 2006
New Revision: 397574

URL: http://svn.apache.org/viewcvs?rev=397574&view=rev
Log:
remove an uneccessary System.out.println statement 


Modified:

incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/mapper/DefaultActionMapper.java

Modified: 
incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/mapper/DefaultActionMapper.java
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/mapper/DefaultActionMapper.java?rev=397574&r1=397573&r2=397574&view=diff
==
--- 
incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/mapper/DefaultActionMapper.java
 (original)
+++ 
incubator/webwork2/action/src/main/java/org/apache/struts/action2/dispatcher/mapper/DefaultActionMapper.java
 Thu Apr 27 08:47:13 2006
@@ -279,10 +279,6 @@
 static List getExtensions() {
 String extensions = (String) 
Configuration.get(StrutsConstants.STRUTS_ACTION_EXTENSION);
 
-if (extensions == null) {
-System.out.println(Configuration.getConfiguration().getClass());
-}
-
 if ("".equals(extensions)) {
return null;
 } else {



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

svn commit: r397573 - /struts/sandbox/trunk/tiles/src/java/org/apache/tiles/TilesContext.java

2006-04-27 Thread greddin

Author: greddin
Date: Thu Apr 27 08:47:12 2006
New Revision: 397573

URL: http://svn.apache.org/viewcvs?rev=397573&view=rev
Log:
STR-2730

First hack at an interface for TilesContext.  This interface will serve to 
replace Servlet API dependencies in Tiles.


Added:
struts/sandbox/trunk/tiles/src/java/org/apache/tiles/TilesContext.java   
(with props)

Added: struts/sandbox/trunk/tiles/src/java/org/apache/tiles/TilesContext.java
URL: 
http://svn.apache.org/viewcvs/struts/sandbox/trunk/tiles/src/java/org/apache/tiles/TilesContext.java?rev=397573&view=auto
==
--- struts/sandbox/trunk/tiles/src/java/org/apache/tiles/TilesContext.java 
(added)
+++ struts/sandbox/trunk/tiles/src/java/org/apache/tiles/TilesContext.java Thu 
Apr 27 08:47:12 2006
@@ -0,0 +1,78 @@
+/*
+ * $Id$
+ *
+ * Copyright 1999-2004 The Apache Software Foundation.
+ * 
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ * 
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.tiles;
+
+import java.util.Map;
+
+/**
+ * Contains hooks to the application execution environment.
+ *
+ * @version $Rev$ $Date$
+ */
+public interface TilesContext {
+
+/**
+ * Returns a mutable Map that maps application scope attribute names to 
+ * their values.
+ */
+public Map getApplicationScope();
+
+/**
+ * Return an immutable Map that maps header names to the first (or only) 
+ * header value (as a String).
+ */
+public Map getHeader();
+
+/**
+ * Return an immutable Map that maps header names to the set of all values 
+ * specified in the request (as a String array). Header names must be 
+ * matched in a case-insensitive manner.
+ */
+public Map getHeaderValues();
+
+/**
+ * Return an immutable Map that maps context application initialization 
+ * parameters to their values.
+ */
+public Map getInitParmas();
+
+/**
+ * Return an immutable Map that maps request parameter names to the first 
+ * (or only) value (as a String).
+ */
+public Map getParam();
+
+/**
+ * Return an immutable Map that maps request parameter names to the set of 
+ * all values (as a String array).
+ */
+public Map getParamValues();
+
+/**
+ * Return a mutable Map that maps request scope attribute names to their 
+ * values.
+ */
+public Map getRequestScope();
+
+/**
+ * Return a mutable Map that maps session scope attribute names to their 
+ * values.
+ */
+public Map getSessionScope();
+}

Propchange: 
struts/sandbox/trunk/tiles/src/java/org/apache/tiles/TilesContext.java
--
svn:eol-style = native

Propchange: 
struts/sandbox/trunk/tiles/src/java/org/apache/tiles/TilesContext.java
--
svn:keywords = Date Author Id Revision HeadURL



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

[jira] Commented: (STR-2730) [Standalone Tiles\ Remove Servlet API Dependencies

2006-04-27 Thread Greg Reddin (JIRA)

[ 
http://issues.apache.org/struts/browse/STR-2730?page=comments#action_37212 ] 

Greg Reddin commented on STR-2730:
--

Committed TilesContext interface.  It is modeled after the WebContext of 
Commons-Chain.  I thought about modeling it after JSF's ExternalContext, but 
Chain's WebContext seems to be closer to what we are looking for.  But I'm open 
to suggestions.  The next step is to update the core API to use TilesContext 
and complete fleshing out the Context interface.  Then we'll need some concrete 
implementations of the interface.

> [Standalone Tiles\ Remove Servlet API Dependencies
> --
>
>  Key: STR-2730
>  URL: http://issues.apache.org/struts/browse/STR-2730
>  Project: Struts Action 1
> Type: Improvement

>   Components: Sandbox
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
> Reporter: Greg Reddin
> Assignee: Struts Developer Mailing List
> Priority: Minor

>
> Once the core library is ready we need to refine the API again to depend on a 
> context class instead of 
> Servlet classes. This will allow Tiles to be used within JSF and Portlet 
> environments. Look at commons-
> chain and JSF for ideas.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: Linking SVN to JIRA

2006-04-27 Thread Ted Husted

I've been meaning to ask if the JIRA-SVN plugin is installed. If it
is, then all you have to do is reference the JIRA ticket in the SVN
log. The only trick is to be sure the JIRA reference is a standalone
string, and not punctuated or formatted.

Bad
* [STR-1234]

Good
* STR-1234

Or even something like

* Resolved STR-1234 by doing this, that, and the other thing.

But that only works if we have the plugin installed.

* http://jira.atlassian.com/browse/JRA-3312

-Ted.

On 4/27/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
> I'm getting ready to make some commits and I'd like to link them to
> JIRA tickets.  Is there a way to format the commit message so that
> JIRA or something will automatically associate the commit with the
> ticket?  I've seen this discussed before but I'm not sure if I've
> seen the specifics for how to do it.  Sorry if it's widely known and
> I somehow missed it.
>
> Greg

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

Re: Proposal for change

On 4/27/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote:
> Dakota Jack wrote:
> > Doesn't this kind of talk sound goofy to you all?  Isn't this reference to
> > the Apache Way sort of like a secret handshake and a silly hat?
>
> It's all that, yes, but it's also not very honest, I'd say.
>
> You see, the various scripture on the so-called "Apache Way" claims that
> the ASF is run as a "meritocracy". What you see here is that the Struts
> committers, after years of not achieving much, have invited in the
> Webwork people with the intention of relabelling Webwork as Struts
> Action 2 (when the existing Struts codebase is Struts Action 1). They
> tacitly accept that the Webwork people ran the better project
> technically, did the better work.
>
> Well, once you accept that the other people did the better work, and you
> have a meritocracy, then those other people, who have more merit, they
> run the show.
>
> The logic of this looks unassailble to me.

That's because you don't understand what you're talking about.  The
"meritocracy" idea at Apache is not about who does the work best. 
It's just about who does the work.  You do the work, you make
decisions.

> So, by what basic principle does the existing Struts PMC remain in
> control of the project when they accept that the other people did better
> work?
>
> The only principle I see is the principle of incumbency or tenure.

That's a problem with your vision.  There are plenty of reasons:

1) it's more about doing the work than doing the work "better".
2) SAF 2/WebWork is still in incubation.  It's not even actually part
of Struts yet.
3) The Struts PMC currently oversees Shale, Tiles, and SAF 1.  WebWork
is not the only project here.

> When people who did inferior work remain the managers of a project (and
> ostensibly manage the people who did the better work) and this is by
> virtue of incumbency or tenure, you don't have a meritocracy.

And all you have is a strawman.  Pay attention to how things actually
are run around here.  The PMC doesn't "manage" other committers.  In
practice, any committer's -1 is as meaningful as a PMC members.  In
fact, if a contributor who is not a committer has something to say
about the code they've contributed, then the PMC will respect that
too.  In fact, i'm fairly sure these principles are actually codified
somewhere in the "Apache scriptures".  Them that do the work make the
decisions.  That's a meritocracy, if you ask me.

Oh, and i seem to recall reading once in a Jakarta discussion that the
ideal situation to the ASF is if all committers for a project are on
the PMC that oversees the project.  Does that sound like it has
anything to do with who does better work? hmm.

> So, actually, seriously applying the principles outlined about
> meritocracy would necessarily imply an extreme shake-up in the Struts
> project. However, in a typically ass backwards way, the "Apache Way"
> stuff is being used as a rhetorical instrument to quell dissent --
> "don't rock the boat". As another example of ass backwards rhetoric, in
> his "This has gone too far" post, Don Brown implies that the reason for
> a lack of forward progress is the presence of that discussion. But that
> is 180º away. That and other such discussions came about precisely
> because of the lack of forward progress. The causality is in completely
> the other direction.
>
> Of course, it's clear why there's an attempt to shut down any discussion
> that casts doubt on the way in which certain people are club members and
> others are not. It has nothing to do with any "Apache Way". It can't be
> openly discussed because, in reality, the incumbent managers of the
> project do not have a leg to stand on. If they accepted the basic logic
> of a meritocracy, Don and Ted and the rest would have to just resign and
> let new people in.

If they accepted your personally expedient definition of a
meritocracy, then maybe.  But Apache doesn't care what Jonathan
Revusky thinks, because Jonathan Revusky doesn't do a lick of work for
the ASF community (much like me).  It is you and i who have no legs to
stand on here.  Don and Ted do tons of work, and therefore have all
the legs they need and more.  Just pay attention to this list for a
week and that will be obvious.

> Jonathan Revusky
> --
> lead developer, FreeMarker project, http://freemarker.org/
> lead anti-Apache troll, http://freemarker.blogspot.com/
>
>
>
>
>
>
>
>
> > Let's say
> > what the Struts Way is.  It is not, I would strongly suggest even slightly
> > related to the Apache Way.  I am also strongly considering just never coming
> > back here.  I am getting just to sick of the plain and unvarinshed stupidity
> > on this list.
> >
> > On 4/25/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> >
> >>On 4/25/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> >>
> >>>On Tue, April 25, 2006 2:22 pm, Paul Speed said:
> >>>
> 
> Frank W. Zammetti wrote:
> 
> 
> >You are of course right about this.  But, much

[jira] Created: (WW-1300) Unwanted locale-formatting of checkbox values

2006-04-27 Thread Dennis Doubleday (JIRA)

Unwanted locale-formatting of checkbox values
-

 Key: WW-1300
 URL: http://issues.apache.org/struts/browse/WW-1300
 Project: Struts Action 2
Type: Bug

  Components: Views  
Versions: WW 2.2.2
 Environment: Windows XP, FreeMarker for view
Reporter: Dennis Doubleday
Priority: Minor


See User Forum thread 
http://forums.opensymphony.com/thread.jspa?threadID=28212&tstart=0 for context.

We are using a checkbox list like this:

<@ww.checkboxlist label="Roles" name="roleIds" list="roleMap"/>

The "roleMap" is a Map. The output of this is:


newrole

User

adminall

Note that second one--the Long value gets written as "4,704". The comma causes 
a conversion error when the form is submitted. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

svn commit: r397577 - in /incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree: Category.java GetCategory.java Toggle.java

Author: tmjee
Date: Thu Apr 27 09:07:15 2006
New Revision: 397577

URL: http://svn.apache.org/viewcvs?rev=397577&view=rev
Log:
 - added ASF license declaration
 - remove @author tag
 - both in accordance to ASF policy


Modified:

incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Category.java

incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/GetCategory.java

incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Toggle.java

Modified: 
incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Category.java
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Category.java?rev=397577&r1=397576&r2=397577&view=diff
==
--- 
incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Category.java
 (original)
+++ 
incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Category.java
 Thu Apr 27 09:07:15 2006
@@ -1,3 +1,20 @@
+/*
+ * $Id: AjaxTestAction.java 394498 2006-04-16 15:28:06Z tmjee $
+ *
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
 package org.apache.struts.action2.showcase.ajax.tree;
 
 import java.util.HashMap;
@@ -6,7 +23,6 @@
 import java.util.ArrayList;
 
 /**
- * @author mailto:[EMAIL PROTECTED]">Patrick Lightbody
  */
 public class Category {
 private static Map catMap = new HashMap();

Modified: 
incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/GetCategory.java
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/GetCategory.java?rev=397577&r1=397576&r2=397577&view=diff
==
--- 
incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/GetCategory.java
 (original)
+++ 
incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/GetCategory.java
 Thu Apr 27 09:07:15 2006
@@ -1,9 +1,25 @@
+/*
+ * $Id: AjaxTestAction.java 394498 2006-04-16 15:28:06Z tmjee $
+ *
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
 package org.apache.struts.action2.showcase.ajax.tree;
 
 import com.opensymphony.xwork.ActionSupport;
 
 /**
- * @author mailto:[EMAIL PROTECTED]">Patrick Lightbody
  */
 public class GetCategory extends ActionSupport {
 private long catId;

Modified: 
incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Toggle.java
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Toggle.java?rev=397577&r1=397576&r2=397577&view=diff
==
--- 
incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Toggle.java
 (original)
+++ 
incubator/webwork2/webapps/showcase/src/main/java/org/apache/struts/action2/showcase/ajax/tree/Toggle.java
 Thu Apr 27 09:07:15 2006
@@ -1,9 +1,25 @@
+/*
+ * $Id: AjaxTestAction.java 394498 2006-04-16 15:28:06Z tmjee $
+ *
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "A

Re: Linking SVN to JIRA

2006-04-27 Thread Martin Cooper

On 4/27/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> I've been meaning to ask if the JIRA-SVN plugin is installed.


Yes, it's installed and working. For example, see:

http://issues.apache.org/struts/browse/WW-1299

There does appear to be a lag, though, between the commit and when the link
shows up.

--
Martin Cooper


If it
> is, then all you have to do is reference the JIRA ticket in the SVN
> log. The only trick is to be sure the JIRA reference is a standalone
> string, and not punctuated or formatted.
>
> Bad
> * [STR-1234]
>
> Good
> * STR-1234
>
> Or even something like
>
> * Resolved STR-1234 by doing this, that, and the other thing.
>
> But that only works if we have the plugin installed.
>
> * http://jira.atlassian.com/browse/JRA-3312
>
> -Ted.
>
>
> On 4/27/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
> > I'm getting ready to make some commits and I'd like to link them to
> > JIRA tickets.  Is there a way to format the commit message so that
> > JIRA or something will automatically associate the commit with the
> > ticket?  I've seen this discussed before but I'm not sure if I've
> > seen the specifics for how to do it.  Sorry if it's widely known and
> > I somehow missed it.
> >
> > Greg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[jira] Reopened: (STR-1341) should include "action" attribute

 [ http://issues.apache.org/struts/browse/STR-1341?page=all ]
 
David Evans reopened STR-1341:
--

Assign To: (was: Struts Developer Mailing List)

>  should include "action" attribute
> 
>
>  Key: STR-1341
>  URL: http://issues.apache.org/struts/browse/STR-1341
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
> Reporter: Dan Allen
> Priority: Minor

>
> I find the missing "action" attribute in html:rewrite inconsistent.  An effort
> was made to include an "action" attribute in html:link so that the mapping
> information could be referenced in the struts-config.xml.  The html:rewrite, 
> an
> extention of the html:link tag overlooks this attribute even though its use 
> can
> be equally as important since the html:rewrite is simply the href rendering of
> the html:link tag extracted for purposes when the html anchor tag is 
> inappropriate.
> After reviewing the code, this field already belongs to LinkTag which 
> RewriteTag
> extends so adding this would be 1 line change in RewriteTag (calling the 
> updated
> RequestUtils.computeURL() and add the attribute to the 
> struts-html.tlddone.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Resolved: (STR-1341) should include "action" attribute

 [ http://issues.apache.org/struts/browse/STR-1341?page=all ]
 
David Evans resolved STR-1341:
--

Resolution: Duplicate

>  should include "action" attribute
> 
>
>  Key: STR-1341
>  URL: http://issues.apache.org/struts/browse/STR-1341
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
> Reporter: Dan Allen
> Priority: Minor

>
> I find the missing "action" attribute in html:rewrite inconsistent.  An effort
> was made to include an "action" attribute in html:link so that the mapping
> information could be referenced in the struts-config.xml.  The html:rewrite, 
> an
> extention of the html:link tag overlooks this attribute even though its use 
> can
> be equally as important since the html:rewrite is simply the href rendering of
> the html:link tag extracted for purposes when the html anchor tag is 
> inappropriate.
> After reviewing the code, this field already belongs to LinkTag which 
> RewriteTag
> extends so adding this would be 1 line change in RewriteTag (calling the 
> updated
> RequestUtils.computeURL() and add the attribute to the 
> struts-html.tlddone.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-1341) should include "action" attribute

 [ http://issues.apache.org/struts/browse/STR-1341?page=all ]
 
David Evans closed STR-1341:



>  should include "action" attribute
> 
>
>  Key: STR-1341
>  URL: http://issues.apache.org/struts/browse/STR-1341
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
> Reporter: Dan Allen
> Priority: Minor

>
> I find the missing "action" attribute in html:rewrite inconsistent.  An effort
> was made to include an "action" attribute in html:link so that the mapping
> information could be referenced in the struts-config.xml.  The html:rewrite, 
> an
> extention of the html:link tag overlooks this attribute even though its use 
> can
> be equally as important since the html:rewrite is simply the href rendering of
> the html:link tag extracted for purposes when the html anchor tag is 
> inappropriate.
> After reviewing the code, this field already belongs to LinkTag which 
> RewriteTag
> extends so adding this would be 1 line change in RewriteTag (calling the 
> updated
> RequestUtils.computeURL() and add the attribute to the 
> struts-html.tlddone.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-1318) contextRelative enhancement to tag

 [ http://issues.apache.org/struts/browse/STR-1318?page=all ]
 
David Evans reopened STR-1318:
--

Assign To: (was: Ted Husted)

> contextRelative enhancement to  tag
> 
>
>  Key: STR-1318
>  URL: http://issues.apache.org/struts/browse/STR-1318
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: James CE Johnson
> Priority: Minor
>  Fix For: 1.1.1

>
> This is an addition to my enhancement request in STR-1317. The above patch
> includes those changes as well.
> Similar to my use of  in that bug, I have a need for this kind of
> thing:
>page="/images/header/stripes.gif"/>"
>   ...
> Without the new contextRelative attribute, the  will insert 
> the
> module's prefix which, of course, breaks the image links. Like the earlier
> change to  the contextRelative prevents the module prefix being
> inserted into the output.
> In order to implement this, I had to modify RequestUtils.computeURL() which I
> really didn't want to do. However, it is handling all of the URL resolution 
> for
> the RewriteTag and I didn't see a cleaner solution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-1318) contextRelative enhancement to tag

 [ http://issues.apache.org/struts/browse/STR-1318?page=all ]
 
David Evans closed STR-1318:


Resolution: Duplicate

> contextRelative enhancement to  tag
> 
>
>  Key: STR-1318
>  URL: http://issues.apache.org/struts/browse/STR-1318
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: James CE Johnson
> Priority: Minor
>  Fix For: 1.1.1

>
> This is an addition to my enhancement request in STR-1317. The above patch
> includes those changes as well.
> Similar to my use of  in that bug, I have a need for this kind of
> thing:
>page="/images/header/stripes.gif"/>"
>   ...
> Without the new contextRelative attribute, the  will insert 
> the
> module's prefix which, of course, breaks the image links. Like the earlier
> change to  the contextRelative prevents the module prefix being
> inserted into the output.
> In order to implement this, I had to modify RequestUtils.computeURL() which I
> really didn't want to do. However, it is handling all of the URL resolution 
> for
> the RewriteTag and I didn't see a cleaner solution.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[Struts Wiki] Update of "RoughSpots" by DonBrown

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by DonBrown:
http://wiki.apache.org/struts/RoughSpots

--
  I'm new around here, so be nice ;)  I probably have a lot less WW experience 
than most, so I apologize in advance if I'm flat out wrong about some of the 
things here.
  
1. How does WW help the user with state management?  As far as I can tell, 
if I want to keep a 'user' object around I have to interact with the map 
returned by ActionContext.getSession().  Actions should in general have a 
type-safe and transparent way to do this, e.g. by subclassing ActionContext and 
providing getUser()/setUser() which store the user in session.  This allows for 
re-working of the storage strategy (e.g. write a cookie and lookup the user 
each time) without affecting actions.
- 
  * [crazybob] I prefer an injection-based approach. You can use the 
`ScopeInterceptor` to pull an object off the session and pass it to your 
action. Or you can use Spring to inject session-scoped objects into your action 
(though I would avoid Spring personally).
- 
  * [jcarreira] I can attest that the Spring scoped components work well 
with WebWork. It's what we use at work for maintaining session or request state.
  
1. In tandem with the previous point, since Actions are already stateful, 
it'd be nice to have the ActionContext injected into the Action.  One benefit 
is when a newbie developer needs it, the linkage is obvious (they don't have to 
a priori know about the ActionContext, they're being handed in it on a 
platter). If the developer can subclass ActionContext, it would also encourage 
them to implement a base action which accepts the context inject and leveraging 
the fact that JDK 1.5 allows co-variant returns, also write a getContext() 
method that returns the down-casted type; they wouldn't have to do 
((MyActionContext) ActionContext.getContext()).getUser() for example, just 
getContext().getUser().
  * [frankz] This might well address the issue of !ActionContext being 
!ThreadLocal.  If it was injected, it wouldn't need to be !ThreadLocal to get 
the same basic effect, and maybe more importantly, it wouldn't automatically be 
available to helper classes as it is as a !ThreadLocal.  That would address my 
concern about "inappropriate" usage of !ActionContext.
  * [jcarreira] I think this is a bad idea, in general. Actions should 
specify the exact things they need and have them supplied, not just ask for the 
"world" (the ActionContext is the world the action lives in). 
+ * [mrdon] While I agree more specific is generally better, I like the 
idea of the user being able to subclass ActionContext for their particular 
application.  Tapestry has the Visit object (I think that's the name) I've 
always liked.
+ 
-   1. HTML analog tags should stick to HTML attributes. I dont' mean they 
shouldn't have more functionality, but the attributes should be identical where 
possible, and they shouldn't do things like render a label and an input.  
Keeping them more like regular HTML tags makes them easier to ramp up on, and 
more non-developer friendly
+   1. HTML analog tags should stick to HTML attributes. I don't mean they 
shouldn't have more functionality, but the attributes should be identical where 
possible, and they shouldn't do things like render a label and an input.  
Keeping them more like regular HTML tags makes them easier to ramp up on, and 
more non-developer friendly
  * [MJ] I see the following options when it comes to tags. (1) Use plain 
HTML + implicit scoped variables like "actionName", "actionAddress", etc. to 
create dynamic values; this looks pretty compact with JSP 2.0. (2) Use 1:1 
relation between WW tags and HTML tags. (3) Use 1:M relation between WW tags 
and HTML tags, like to create data entry form or a table. (4) Use 
non-HTML-looking tags + more abstract attributes + "media" attribute, thus 
creating something like JSF renderer for different media. Choosing between (1) 
and (2) I prefer the first one.
- * I'd encourage people to give the ww: tags a spin... they're really much 
more powerful than the JSTL or previous struts tags and you don't need so many 
tags to do things. On being closer to HTML attributes, do you have some 
examples?
+ * [jcarreira] I'd encourage people to give the ww: tags a spin... they're 
really much more powerful than the JSTL or previous struts tags and you don't 
need so many tags to do things. On being closer to HTML attributes, do you have 
some examples?
+ * [mrdon] +1 for aligning attributes with HTML attributes
  
1. Actions should return concrete objects, not symbolic results.  Symbolic 
results might have been optimal when you had one event/method per action and 
the outcomes were always whole-page views, but they get in the way now.  Wh

Re: Proposal for change

2006-04-27 Thread Dakota Jack

People do not do "work" around here because it is not rewarded.  The
people who are rewarded are political.  Then they do the work and the
work looks like coding by politicians.  I can remember going into the
file upload section and seeing one of the worst messes I have ever
seen in an open source project.  There are hanging references and
other monstrosities that I had only seen community college class
assignments prior to looking at Struts code.  I could not even discuss
the code much less have any hope of helping, because the committers
use this for their work and are not amenable to good code but rather
to code that advances their careers.

If you think that Jonathan or I have nothing to contribute, you are
sadly mistaken.  We are quite aware of the nature of this beast.  You
really need to pay attention to what is going on.  There is nothing
like a meritocracy around here.  How do you think that Struts 1.x
managed to become a plate of spaghetti after such a fine start?

Mertiocracy does not mean just work, by the way.  It means work with
merit.  This not sold as a "docracy" or "actcracy".  Get a clue.

On 4/27/06, Daniel Warner <[EMAIL PROTECTED]> wrote:
> > The only principle I see is the principle of incumbency or tenure.
>
> That's a problem with your vision.  There are plenty of reasons:
>
> 1) it's more about doing the work than doing the work "better".
> 2) SAF 2/WebWork is still in incubation.  It's not even actually part
> of Struts yet.
> 3) The Struts PMC currently oversees Shale, Tiles, and SAF 1.  WebWork
> is not the only project here.

--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: [PROPOSAL] Separate lists for notifications vs. discussion

2006-04-27 Thread Patrick Lightbody

Actually, you probably still want a jira@ or notifications@ list - only because 
those watches don't notify you of every change. They only let you know when an 
issue is added or removed from the list (opened or resolved), but not when it 
is commented on. I think.

I asked Scott @ Atlassian about improving this and he said it is part of a 
larger effort with roles they are working on. In the meantime, an mailing list 
for each service (as well as RSS alternatives) is a good way to go.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=27726&messageID=54981#54981


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

[jira] Commented: (WW-1300) Unwanted locale-formatting of checkbox values

2006-04-27 Thread Philip Luppens (JIRA)

[ http://issues.apache.org/struts/browse/WW-1300?page=comments#action_37213 
] 

Philip Luppens commented on WW-1300:


Well, I found it .. in the select template, they are actually doing:

<#assign itemKeyStr = itemKey.toString() />

So I guess we should simply do the same for the checkboxlist .. could you file 
an issue at the Jira ? I'll patch it tomorrow, but you can do it yourself if 
you like by extending themes (see the wiki docs) and copying the 
template/simple/checkboxlist.ftl and patching it as follows:

<#rt/>

to:

<#assign itemKeyStr = itemKey.toString() />
<#rt/>


> Unwanted locale-formatting of checkbox values
> -
>
>  Key: WW-1300
>  URL: http://issues.apache.org/struts/browse/WW-1300
>  Project: Struts Action 2
> Type: Bug

>   Components: Views
> Versions: WW 2.2.2
>  Environment: Windows XP, FreeMarker for view
> Reporter: Dennis Doubleday
> Priority: Minor

>
> See User Forum thread 
> http://forums.opensymphony.com/thread.jspa?threadID=28212&tstart=0 for 
> context.
> We are using a checkbox list like this:
> <@ww.checkboxlist label="Roles" name="roleIds" list="roleMap"/>
> The "roleMap" is a Map. The output of this is:
> 
> newrole
> 
> User
> 
> adminall
> Note that second one--the Long value gets written as "4,704". The comma 
> causes a conversion error when the form is submitted. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: closing and reopening jira issues

2006-04-27 Thread Don Brown


Leon Rosenberg wrote:

On 4/27/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:

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

The resolved/closed question is interesting.  I guess they could be
resolved, but reviewed and closed by the release manager.  Otherwise,
I'd agree that they seem to function the same for open source projects
anyways.


In my day job scenario, we have the developers who commit changes switch an
issue to "Resolved", and then QE verifies the result and switches it to
"Closed".  I'd hate to see us stick all of that responsibility solely on a
release manager right before a release (doubt we'd ever get a volunteer to
do it twice :-), but maybe we could have the release manager declare a
moratorium on changes, and then have all the committers take on the task of
verifying the issues that have been purported to be fixed?



Here (in our team) the developers switch the issues to DONE (bugzilla)
and the reporter of the issue (QA or anyone else) is responsible to
CLOSE the issue and resolve it as fixed (or reopen it, if it's not
fixed).
Could it be a possible scenario for struts-issues too? The reporter of
an issue whould have a natural interest in checking the fix and
confirming it.


I like that, and if they don't close it by the release, the release manager 
will close it.

Don



regards


Craig



Leon

-
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: closing and reopening jira issues

2006-04-27 Thread Ted Husted

On 4/27/06, Don Brown <[EMAIL PROTECTED]> wrote:
> I like that, and if they don't close it by the release, the release manager 
> will close it.

I don't understand why we should set this up so every ticket has to be
closed twice. The tickets are already subject to peer-review by the
PMC and all the subscribers to dev@ (or issues@). We have nightly
builds going out every day that reflect the changes made by the
tickets.

If the problem is fixed, then the release testing should prove that it
is fixed. I don't believe that we should be turing the release manager
into some type of clerical assistant or gatekeeper for the rest of us.
If the RM wants to review the tickets that have been closed since the
last relesae, that's fine. But I would suggest that we not try to dump
any additional responsibility on this role. It's a hard enough job as
it is.

My suggestion would be that whoever applies the patch should also
supply a test that proves the issue is resolved, and then closes the
ticket as fixed, until shown otherwise.  It doesn't have to be a fancy
test. In the case of a taglib, it could just be a use case in the
taglib exercise application.

-Ted.

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

[jira] Reopened: (STR-1301) loses index with jsp:include

 [ http://issues.apache.org/struts/browse/STR-1301?page=all ]
 
David Evans reopened STR-1301:
--

Assign To: (was: Struts Developer Mailing List)

>  loses index with jsp:include
> -
>
>  Key: STR-1301
>  URL: http://issues.apache.org/struts/browse/STR-1301
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.1 Final
>  Environment: Operating System: Windows XP
> Platform: PC
> Reporter: Chris Butler
> Priority: Minor
>  Fix For: 1.2 Family
>  Attachments: Names.java, StrutsBaseForm.java, StrutsInnerBean.java, 
> requestScope.jsp, testBase.jsp, testInnerJunk.jsp, testInnerOne.jsp, 
> testInnerTwo.jsp, testNestedIterate.jsp, testNestedIterateInclude.jsp, 
> testNestedIterateInclude.jsp, testNestedIterateInclude2.jsp
>
> POTENTIAL BUG:
> When using nested:interate and placing a jsp:include in the iteration, the
> included jsp cannot retrieve the proper nesting level.  Thus any form related
> nested tags are possibly named with duplicate names.  ie:
> 
> 
> COMMENT OF NOTE:
> It appears that tag does *NOT* lose the actual underlying beans, 
> it just loses the proper naming of the index.
> SIMPLE EXAMPLE:
> *** testNestedIterate.jsp = 
> 
>   
> BEFORE: 
> 
>   
> 
> *** testNestedIterateInclude.jsp =
> 
>   AFTER: 
>   Name in bytes: 
> 
> I will attach the test class throwaway.test.Names 
> in a subsequent comment to help document this problem better.
> I've tried to seriously test this before submitting this as
> bug so if any further information is needed please reach me
> at [EMAIL PROTECTED]

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: closing and reopening jira issues

2006-04-27 Thread Don Brown

I agree with everything you said, save the RM difficulty level. All I'm saying is the RM should look over the list of
all fixed tickets ensuring everything is in order. Thanks to Wendy, the RM can roll a release in under a hour with most
of that time taking up waiting for Maven to do its thing. She is even working on a way to automatically deploy the
example applications and run rudimentary tests.

I guess I see the RM as the one responsible for the release. It isn't a bad thing and ideally, they will have no
additional work; I certainly didn't have much when I rolled the release last nite.

Don

Ted Husted wrote:

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

I like that, and if they don't close it by the release, the release manager
will close it.

I don't understand why we should set this up so every ticket has to be
closed twice. The tickets are already subject to peer-review by the
PMC and all the subscribers to dev@ (or issues@). We have nightly
builds going out every day that reflect the changes made by the
tickets.

If the problem is fixed, then the release testing should prove that it
is fixed. I don't believe that we should be turing the release manager
into some type of clerical assistant or gatekeeper for the rest of us.
If the RM wants to review the tickets that have been closed since the
last relesae, that's fine. But I would suggest that we not try to dump
any additional responsibility on this role. It's a hard enough job as
it is.

My suggestion would be that whoever applies the patch should also
supply a test that proves the issue is resolved, and then closes the
ticket as fixed, until shown otherwise. It doesn't have to be a fancy
test. In the case of a taglib, it could just be a use case in the
taglib exercise application.

-Ted.

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

[jira] Reopened: (STR-263) additional constructor for ActionError

 [ http://issues.apache.org/struts/browse/STR-263?page=all ]
 
David Evans reopened STR-263:
-


> additional constructor for ActionError
> --
>
>  Key: STR-263
>  URL: http://issues.apache.org/struts/browse/STR-263
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.0 Final
>  Environment: Operating System: other
> Platform: Other
> Reporter: Will Jaynes
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family

>
> Add a constuctor to ActionError to allow passing in of an array of Objects
> for the replacement values. This would remove the limit of 4 replacement
> values and conform more with the way one uses java.text.MessageFormat.
> Plus it would be much more convenient for when the number of replacement
> values is determined at run time.
> Will Jaynes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-263) additional constructor for ActionError

 [ http://issues.apache.org/struts/browse/STR-263?page=all ]
 
David Evans closed STR-263:
---

Resolution: Fixed

> additional constructor for ActionError
> --
>
>  Key: STR-263
>  URL: http://issues.apache.org/struts/browse/STR-263
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.0 Final
>  Environment: Operating System: other
> Platform: Other
> Reporter: Will Jaynes
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family

>
> Add a constuctor to ActionError to allow passing in of an array of Objects
> for the replacement values. This would remove the limit of 4 replacement
> values and conform more with the way one uses java.text.MessageFormat.
> Plus it would be much more convenient for when the number of replacement
> values is determined at run time.
> Will Jaynes

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-241) Change to use a collection like

 [ http://issues.apache.org/struts/browse/STR-241?page=all ]
 
David Evans reopened STR-241:
-


> Change  to use a collection like 
> 
>
>  Key: STR-241
>  URL: http://issues.apache.org/struts/browse/STR-241
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jim Richards
> Assignee: Craig McClanahan
> Priority: Minor

>
> Why does  use a collection as 
>   A runtime expression that evaluates to a collection to be iterated over.
> and 
>   Name of the JSP bean (in some scope) which is itself a Collection of 
> other
>   beans, each of which has properties named by the "property" and 
> "labelProperty"
>   attributes that are used to retrieve the value and label for each 
> option,
>   respectively. [RT Expr] 
> effective, if I use  I can do (something like) this
>   ">
>   
> which is really handy, but for  I have to do
> <% pageContext.setAttribute("catalog", myCatalogCollection); %>
> 
>  labelProperty="value.description"/>
> 
> I'd rather have in the middle
>  labelProperty="value.description"/>
> or similar, like I can do with iterate.
> Or put better from the index of the javadoc
>   setCollection(Object) - Method in class 
> org.apache.struts.taglib.EnumerateTag
>   Set the collection over which we will be enumerating. 
>   setCollection(Object) - Method in class 
> org.apache.struts.taglib.IterateTag 
>   Set the collection over which we will be iterating. 
>   setCollection(Object) - Method in 
> class org.apache.struts.taglib.bean.SizeTag 
>   setCollection(Object) - Method in class 
> org.apache.struts.taglib.logic.IterateTag 
>   setCollection(String) - Method in class 
> org.apache.struts.taglib.html.OptionsTag 
>
> Spot the odd one out.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-241) Change to use a collection like

 [ http://issues.apache.org/struts/browse/STR-241?page=all ]
 
David Evans closed STR-241:
---

Resolution: Fixed

> Change  to use a collection like 
> 
>
>  Key: STR-241
>  URL: http://issues.apache.org/struts/browse/STR-241
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
> Reporter: Jim Richards
> Assignee: Craig McClanahan
> Priority: Minor

>
> Why does  use a collection as 
>   A runtime expression that evaluates to a collection to be iterated over.
> and 
>   Name of the JSP bean (in some scope) which is itself a Collection of 
> other
>   beans, each of which has properties named by the "property" and 
> "labelProperty"
>   attributes that are used to retrieve the value and label for each 
> option,
>   respectively. [RT Expr] 
> effective, if I use  I can do (something like) this
>   ">
>   
> which is really handy, but for  I have to do
> <% pageContext.setAttribute("catalog", myCatalogCollection); %>
> 
>  labelProperty="value.description"/>
> 
> I'd rather have in the middle
>  labelProperty="value.description"/>
> or similar, like I can do with iterate.
> Or put better from the index of the javadoc
>   setCollection(Object) - Method in class 
> org.apache.struts.taglib.EnumerateTag
>   Set the collection over which we will be enumerating. 
>   setCollection(Object) - Method in class 
> org.apache.struts.taglib.IterateTag 
>   Set the collection over which we will be iterating. 
>   setCollection(Object) - Method in 
> class org.apache.struts.taglib.bean.SizeTag 
>   setCollection(Object) - Method in class 
> org.apache.struts.taglib.logic.IterateTag 
>   setCollection(String) - Method in class 
> org.apache.struts.taglib.html.OptionsTag 
>
> Spot the odd one out.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-232) cant remove Attributes from request scope - ERROR when logon.jsp is web-running!

 [ http://issues.apache.org/struts/browse/STR-232?page=all ]
 
David Evans reopened STR-232:
-


> cant remove Attributes from request scope - ERROR when logon.jsp is 
> web-running!
> 
>
>  Key: STR-232
>  URL: http://issues.apache.org/struts/browse/STR-232
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.0 Final
>  Environment: Operating System: All
> Platform: PC
> Reporter: anazarov
> Assignee: Craig McClanahan
> Priority: Critical

>
> Hello dear Struts creators!
> I try to run main Struts example (Struts_Example) from a final release of 
> Struts framework.
> When I call the logon.jsp page I have next error message:
> java.lang.IllegalArgumentException: cant remove Attributes from request scope
>  at org.apache.jasper.runtime.PageContextImpl.removeAttribute
> (PageContextImpl.java:236)
>  at org.apache.struts.taglib.html.FormTag.doEndTag(FormTag.java:591)
>  at _0002flogon_0002ejsplogon_jsp_0._jspService
> (_0002flogon_0002ejsplogon_jsp_0.java:368)
>  at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126)
> 
> It's obviously that this mistake arise when the servlet container is 
> rendering 
> custom tags. In the logon.jsp page there is the next form tags:
> ...
> 
> 
> 
>  fields for input
> 
> 
> When the container receives a tag  it runs the doEndTag() method 
> from org.apache.struts.taglib.html.FormTag object.
> Error arise in the code:
>   // Remove the page scope attributes we created
>   pageContext.removeAttribute(Constants.BEAN_KEY,
> PageContext.REQUEST_SCOPE);
> ...
> I've walked through the code in the JBuilder's debugger. There is object with 
> key "Constants.BEAN_KEY" in the request scope. But system can't remove a 
> corresponding attribute.
> Please, explore this Struts conduct. I try to run a STANDARD Struts example. 
> I 
> doesn't change anything in there. It worked well in beta realeases of Struts 
> (I'm using Struts from beta 2).
> With best regards.
> Anton Nazarov 
> chief software engineer
> Delta Telecom company 
> RUSSIAN FEDERATION

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-232) cant remove Attributes from request scope - ERROR when logon.jsp is web-running!

 [ http://issues.apache.org/struts/browse/STR-232?page=all ]
 
David Evans closed STR-232:
---

Resolution: Not A Problem

> cant remove Attributes from request scope - ERROR when logon.jsp is 
> web-running!
> 
>
>  Key: STR-232
>  URL: http://issues.apache.org/struts/browse/STR-232
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.0 Final
>  Environment: Operating System: All
> Platform: PC
> Reporter: anazarov
> Assignee: Craig McClanahan
> Priority: Critical

>
> Hello dear Struts creators!
> I try to run main Struts example (Struts_Example) from a final release of 
> Struts framework.
> When I call the logon.jsp page I have next error message:
> java.lang.IllegalArgumentException: cant remove Attributes from request scope
>  at org.apache.jasper.runtime.PageContextImpl.removeAttribute
> (PageContextImpl.java:236)
>  at org.apache.struts.taglib.html.FormTag.doEndTag(FormTag.java:591)
>  at _0002flogon_0002ejsplogon_jsp_0._jspService
> (_0002flogon_0002ejsplogon_jsp_0.java:368)
>  at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126)
> 
> It's obviously that this mistake arise when the servlet container is 
> rendering 
> custom tags. In the logon.jsp page there is the next form tags:
> ...
> 
> 
> 
>  fields for input
> 
> 
> When the container receives a tag  it runs the doEndTag() method 
> from org.apache.struts.taglib.html.FormTag object.
> Error arise in the code:
>   // Remove the page scope attributes we created
>   pageContext.removeAttribute(Constants.BEAN_KEY,
> PageContext.REQUEST_SCOPE);
> ...
> I've walked through the code in the JBuilder's debugger. There is object with 
> key "Constants.BEAN_KEY" in the request scope. But system can't remove a 
> corresponding attribute.
> Please, explore this Struts conduct. I try to run a STANDARD Struts example. 
> I 
> doesn't change anything in there. It worked well in beta realeases of Struts 
> (I'm using Struts from beta 2).
> With best regards.
> Anton Nazarov 
> chief software engineer
> Delta Telecom company 
> RUSSIAN FEDERATION

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

Re: Proposal for change

Please forgive me for feeding the trolls and wasting bandwidth.  I
know, it makes me no better than they are and this apology is
meaningless since I am going to keep doing it for a little while. 
but they are just such cute little trolls with those adorable
nicknames and tiny perspectives!  Seriously, how can you expect anyone
to resist those?! :)

Besides, it is a slow morning for me, and I do not feel like just
lurking as usual. :)  I will understand if you all think less of me
for this utterly juvenile email.  I think less of me too.  Today is
not a good self-control day. :(

On 4/27/06, Dakota Jack <[EMAIL PROTECTED]> wrote:
> People do not do "work" around here because it is not rewarded.
> The people who are rewarded are political.  Then they do the work and the
> work looks like coding by politicians.

Congratulations, that is the stupidest thing I have heard all week! 
You should be rewarded for being so political!  Or did you not know
that playing the opposition means you are a politician too?

> I can remember going into the
> file upload section and seeing one of the worst messes I have ever
> seen in an open source project.  There are hanging references and
> other monstrosities that I had only seen community college class
> assignments prior to looking at Struts code.  I could not even discuss
> the code much less have any hope of helping, because the committers
> use this for their work and are not amenable to good code but rather
> to code that advances their careers.

Then why are you here?  Why do you care if not because you love the
politics?  Admit it, you are just jealous that you are not on the
Struts PMC.  Come on, a little self-awareness will not hurt.  I
promise.

> If you think that Jonathan or I have nothing to contribute, you are
> sadly mistaken.

Awesome!  I love being called "sadly mistaken".  That is so witty and
eloquent!  Now if only i could be called that by a truly famous troll
like Mr. Revusky (there's a little ego stroke for you, JR), my life
would be complete.

But anyway, it is nice of you to "read my mind" and all, but all I was
trying to communicate was that Jonathan and myself had not done any of
the work around here.  I did not say anything about you or anyone's
ability to contribute. (Though I think it is cute that you wanted to
be in on the action. :)

> We are quite aware of the nature of this beast.  You
> really need to pay attention to what is going on.  There is nothing
> like a meritocracy around here.

(In unworthy imitation of the inimitable Bill Cosby)  ..right.

> How do you think that Struts 1.x
> managed to become a plate of spaghetti after such a fine start?

Well, I do not think that.  I know that seems odd to you, but I
actually lurk on this list because I think Struts 1.x was a decently
constructed ham and cheese sandwich.  I am also excited to see it
turning into a delicious BLT with the introduction of WebWork as SAF
2.

> Mertiocracy does not mean just work, by the way.  It means work with
> merit.  This not sold as a "docracy" or "actcracy".

This is the second stupidest thing I have heard all week.  Thank you
for sharing!

> Get a clue.

A clue?  Like the board game?  I love board games!  Would you like to
play a game of "Sorry"?  CandyLand is fun too.

Daniel Warner,
lead time waster and troll feeder
(for today only, I promise I will go back to lurking tomorrow!)

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

[jira] Closed: (STR-155) SSL connection gives error 500: NullPointerExeption at at org.apache.struts.taglib.html.LinkTag.hyperlink(LinkTag.java:497)

 [ http://issues.apache.org/struts/browse/STR-155?page=all ]
 
David Evans closed STR-155:
---

Resolution: Not A Problem

> SSL connection gives error 500: NullPointerExeption at at 
> org.apache.struts.taglib.html.LinkTag.hyperlink(LinkTag.java:497)
> ---
>
>  Key: STR-155
>  URL: http://issues.apache.org/struts/browse/STR-155
>  Project: Struts Action 1
> Type: Bug

>   Components: Apps
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: PC
> Reporter: Daniel Ceuppens
> Assignee: Craig McClanahan

>
> I'm running WebSphere 3.5.3 with IBM-http Server 1.3.12 on a W2k Server.
> I had version struts-1.0-b1 installed and the struts-example worked fine with 
> a 
> non-SSL connection.  But when using my https:// connection, the  tags 
> in index.jsp were not linkable. The text appeared, but withouth href attached.
> So I installed the latest nightly build (jakarta-struts-20010430).
> The http:// connection still works, but the https:// gives the error attached.
> Regards,
> Daniel.
> ===
> Error 500
> An error has occured while processing request:https://rnt.eu-count.com/struts-
> example/index.jsp
> Message: Server caught unhandled exception from servlet [jsp11]: null
> Target Servlet: jsp11
> StackTrace: 
> 
> Root Error-1: null
> java.lang.NullPointerException
>   at org.apache.struts.taglib.html.LinkTag.hyperlink(LinkTag.java:497)
>   at org.apache.struts.taglib.html.LinkTag.doStartTag(LinkTag.java:325)
>   at _index_jsp_2._jspService(_index_jsp_2.java:215)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:127)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service
> (JspServlet.java:381)
>   at org.apache.jasper.runtime.JspServlet.serviceJspFile
> (JspServlet.java:702)
>   at org.apache.jasper.runtime.JspServlet.service(JspServlet.java:822)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   at com.ibm.servlet.engine.webapp.StrictServletInstance.doService
> (ServletManager.java:626)
>   at com.ibm.servlet.engine.webapp.StrictLifecycleServlet._service
> (StrictLifecycleServlet.java:160)
>   at com.ibm.servlet.engine.webapp.IdleServletState.service
> (StrictLifecycleServlet.java:287)
>   at com.ibm.servlet.engine.webapp.StrictLifecycleServlet.service
> (StrictLifecycleServlet.java:105)
>   at com.ibm.servlet.engine.webapp.ServletInstance.service
> (ServletManager.java:360)
>   at com.ibm.servlet.engine.webapp.ValidServletReferenceState.dispatch
> (ServletManager.java:775)
>   at com.ibm.servlet.engine.webapp.ServletInstanceReference.dispatch
> (ServletManager.java:701)
>   at 
> com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.handleWebAppDispatch
> (WebAppRequestDispatcher.java:404)
>   at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.dispatch
> (WebAppRequestDispatcher.java:203)
>   at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.forward
> (WebAppRequestDispatcher.java:107)
>   at com.ibm.servlet.engine.srt.WebAppInvoker.handleInvocationHook
> (WebAppInvoker.java:77)
>   at com.ibm.servlet.engine.invocation.CachedInvocation.handleInvocation
> (CachedInvocation.java:67)
>   at com.ibm.servlet.engine.invocation.CacheableInvocationContext.invoke
> (CacheableInvocationContext.java:106)
>   at com.ibm.servlet.engine.srp.ServletRequestProcessor.dispatchByURI
> (ServletRequestProcessor.java:160)
>   at com.ibm.servlet.engine.oselistener.OSEListenerDispatcher.service
> (OSEListener.java:300)
>   at 
> com.ibm.servlet.engine.oselistener.SQEventListenerImp$ServiceRunnable.run
> (SQEventListenerImp.java:230)
>   at com.ibm.servlet.engine.oselistener.SQEventListenerImp.notifySQEvent
> (SQEventListenerImp.java:104)
>   at 
> com.ibm.servlet.engine.oselistener.serverqueue.SQEventSource.notifyEvent
> (SQEventSource.java:212)
>   at 
> com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$SelectRunnab
> le.notifyService(SQWrapperEventSource.java:353)
>   at 
> com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$SelectRunnab
> le.run(SQWrapperEventSource.java:220)
>   at 
> com.ibm.servlet.engine.oselistener.outofproc.OutOfProcThread$CtlRunnable.run
> (OutOfProcThread.java:248)
>   at java.lang.Thread.run(Thread.java:481)
> 
> Wrapped Error-2: null
> javax.servlet.ServletException
>   at javax.servlet.ServletException.(ServletException.java:161)
>   at org.apache.jasper.runtime.PageContextImpl.handlePageException
> (PageContextImpl.jav

[jira] Reopened: (STR-155) SSL connection gives error 500: NullPointerExeption at at org.apache.struts.taglib.html.LinkTag.hyperlink(LinkTag.java:497)

 [ http://issues.apache.org/struts/browse/STR-155?page=all ]
 
David Evans reopened STR-155:
-


> SSL connection gives error 500: NullPointerExeption at at 
> org.apache.struts.taglib.html.LinkTag.hyperlink(LinkTag.java:497)
> ---
>
>  Key: STR-155
>  URL: http://issues.apache.org/struts/browse/STR-155
>  Project: Struts Action 1
> Type: Bug

>   Components: Apps
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: PC
> Reporter: Daniel Ceuppens
> Assignee: Craig McClanahan

>
> I'm running WebSphere 3.5.3 with IBM-http Server 1.3.12 on a W2k Server.
> I had version struts-1.0-b1 installed and the struts-example worked fine with 
> a 
> non-SSL connection.  But when using my https:// connection, the  tags 
> in index.jsp were not linkable. The text appeared, but withouth href attached.
> So I installed the latest nightly build (jakarta-struts-20010430).
> The http:// connection still works, but the https:// gives the error attached.
> Regards,
> Daniel.
> ===
> Error 500
> An error has occured while processing request:https://rnt.eu-count.com/struts-
> example/index.jsp
> Message: Server caught unhandled exception from servlet [jsp11]: null
> Target Servlet: jsp11
> StackTrace: 
> 
> Root Error-1: null
> java.lang.NullPointerException
>   at org.apache.struts.taglib.html.LinkTag.hyperlink(LinkTag.java:497)
>   at org.apache.struts.taglib.html.LinkTag.doStartTag(LinkTag.java:325)
>   at _index_jsp_2._jspService(_index_jsp_2.java:215)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:127)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service
> (JspServlet.java:381)
>   at org.apache.jasper.runtime.JspServlet.serviceJspFile
> (JspServlet.java:702)
>   at org.apache.jasper.runtime.JspServlet.service(JspServlet.java:822)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   at com.ibm.servlet.engine.webapp.StrictServletInstance.doService
> (ServletManager.java:626)
>   at com.ibm.servlet.engine.webapp.StrictLifecycleServlet._service
> (StrictLifecycleServlet.java:160)
>   at com.ibm.servlet.engine.webapp.IdleServletState.service
> (StrictLifecycleServlet.java:287)
>   at com.ibm.servlet.engine.webapp.StrictLifecycleServlet.service
> (StrictLifecycleServlet.java:105)
>   at com.ibm.servlet.engine.webapp.ServletInstance.service
> (ServletManager.java:360)
>   at com.ibm.servlet.engine.webapp.ValidServletReferenceState.dispatch
> (ServletManager.java:775)
>   at com.ibm.servlet.engine.webapp.ServletInstanceReference.dispatch
> (ServletManager.java:701)
>   at 
> com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.handleWebAppDispatch
> (WebAppRequestDispatcher.java:404)
>   at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.dispatch
> (WebAppRequestDispatcher.java:203)
>   at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.forward
> (WebAppRequestDispatcher.java:107)
>   at com.ibm.servlet.engine.srt.WebAppInvoker.handleInvocationHook
> (WebAppInvoker.java:77)
>   at com.ibm.servlet.engine.invocation.CachedInvocation.handleInvocation
> (CachedInvocation.java:67)
>   at com.ibm.servlet.engine.invocation.CacheableInvocationContext.invoke
> (CacheableInvocationContext.java:106)
>   at com.ibm.servlet.engine.srp.ServletRequestProcessor.dispatchByURI
> (ServletRequestProcessor.java:160)
>   at com.ibm.servlet.engine.oselistener.OSEListenerDispatcher.service
> (OSEListener.java:300)
>   at 
> com.ibm.servlet.engine.oselistener.SQEventListenerImp$ServiceRunnable.run
> (SQEventListenerImp.java:230)
>   at com.ibm.servlet.engine.oselistener.SQEventListenerImp.notifySQEvent
> (SQEventListenerImp.java:104)
>   at 
> com.ibm.servlet.engine.oselistener.serverqueue.SQEventSource.notifyEvent
> (SQEventSource.java:212)
>   at 
> com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$SelectRunnab
> le.notifyService(SQWrapperEventSource.java:353)
>   at 
> com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$SelectRunnab
> le.run(SQWrapperEventSource.java:220)
>   at 
> com.ibm.servlet.engine.oselistener.outofproc.OutOfProcThread$CtlRunnable.run
> (OutOfProcThread.java:248)
>   at java.lang.Thread.run(Thread.java:481)
> 
> Wrapped Error-2: null
> javax.servlet.ServletException
>   at javax.servlet.ServletException.(ServletException.java:161)
>   at org.apache.jasper.runtime.PageContextImpl.handlePageException
> (PageContextImpl.java:386)
>   at _index_j

[jira] Reopened: (STR-54) IterateTag fails on null elements

 [ http://issues.apache.org/struts/browse/STR-54?page=all ]
 
David Evans reopened STR-54:



> IterateTag fails on null elements
> -
>
>  Key: STR-54
>  URL: http://issues.apache.org/struts/browse/STR-54
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.0 Beta 1
>  Environment: Operating System: All
> Platform: PC
> Reporter: Howard Moore
> Assignee: Craig McClanahan
>  Fix For: 1.0.0

>
> If the Collection or array used by an IterateTag contains a null value an 
> exception is thrown when the tag attempts to write it into the PageContext. 
> The 
> alternative would be to remove the attribute if it were null and use 
>  to test for it (see included diff). 
> --- D:\Iterat~1.old   Fri Feb 23 14:36:34 2001
> +++ D:\Iterat~1.java  Mon Feb 26 09:39:22 2001
> @@ -330,7 +330,10 @@
>   // Store the first value and evaluate, or skip the body if none
>   if (iterator.hasNext()) {
>   Object element = iterator.next();
> - pageContext.setAttribute(id, element);
> + if (element == null)
> + pageContext.removeAttribute(id);
> + else
> + pageContext.setAttribute(id, element);
>   lengthCount++;
>   return (EVAL_BODY_TAG);
>  } else
> @@ -358,7 +361,10 @@
>   return (SKIP_BODY);
>   if (iterator.hasNext()) {
>   Object element = iterator.next();
> - pageContext.setAttribute(id, element);
> + if (element == null)
> + pageContext.removeAttribute(id);
> + else
> + pageContext.setAttribute(id, element);
>   lengthCount++;
>   return (EVAL_BODY_TAG);
>   } else

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-54) IterateTag fails on null elements

 [ http://issues.apache.org/struts/browse/STR-54?page=all ]
 
David Evans closed STR-54:
--

Resolution: Fixed

> IterateTag fails on null elements
> -
>
>  Key: STR-54
>  URL: http://issues.apache.org/struts/browse/STR-54
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.0 Beta 1
>  Environment: Operating System: All
> Platform: PC
> Reporter: Howard Moore
> Assignee: Craig McClanahan
>  Fix For: 1.0.0

>
> If the Collection or array used by an IterateTag contains a null value an 
> exception is thrown when the tag attempts to write it into the PageContext. 
> The 
> alternative would be to remove the attribute if it were null and use 
>  to test for it (see included diff). 
> --- D:\Iterat~1.old   Fri Feb 23 14:36:34 2001
> +++ D:\Iterat~1.java  Mon Feb 26 09:39:22 2001
> @@ -330,7 +330,10 @@
>   // Store the first value and evaluate, or skip the body if none
>   if (iterator.hasNext()) {
>   Object element = iterator.next();
> - pageContext.setAttribute(id, element);
> + if (element == null)
> + pageContext.removeAttribute(id);
> + else
> + pageContext.setAttribute(id, element);
>   lengthCount++;
>   return (EVAL_BODY_TAG);
>  } else
> @@ -358,7 +361,10 @@
>   return (SKIP_BODY);
>   if (iterator.hasNext()) {
>   Object element = iterator.next();
> - pageContext.setAttribute(id, element);
> + if (element == null)
> + pageContext.removeAttribute(id);
> + else
> + pageContext.setAttribute(id, element);
>   lengthCount++;
>   return (EVAL_BODY_TAG);
>   } else

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-205) Provide a way to specify xerces and xalan in build.properties

 [ http://issues.apache.org/struts/browse/STR-205?page=all ]
 
David Evans reopened STR-205:
-


> Provide a way to specify xerces and xalan in build.properties
> -
>
>  Key: STR-205
>  URL: http://issues.apache.org/struts/browse/STR-205
>  Project: Struts Action 1
> Type: Improvement

>   Components: Unknown
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: PC
> Reporter: dmiser
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family

>
> It would be nice to have these extra properties available so I don't have to 
> define the JAR files on my CLASSPATH. In build.xml, you could append the 
> values 
> of these properties to the local classpath when compiling.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-205) Provide a way to specify xerces and xalan in build.properties

 [ http://issues.apache.org/struts/browse/STR-205?page=all ]
 
David Evans closed STR-205:
---

Resolution: Not A Problem

> Provide a way to specify xerces and xalan in build.properties
> -
>
>  Key: STR-205
>  URL: http://issues.apache.org/struts/browse/STR-205
>  Project: Struts Action 1
> Type: Improvement

>   Components: Unknown
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: PC
> Reporter: dmiser
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family

>
> It would be nice to have these extra properties available so I don't have to 
> define the JAR files on my CLASSPATH. In build.xml, you could append the 
> values 
> of these properties to the local classpath when compiling.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-1135) Add "action" attribute to

 [ http://issues.apache.org/struts/browse/STR-1135?page=all ]
 
David Evans reopened STR-1135:
--


> Add "action" attribute to 
> 
>
>  Key: STR-1135
>  URL: http://issues.apache.org/struts/browse/STR-1135
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: All
> Reporter: Jeff Butler
> Assignee: Ted Husted
> Priority: Minor
>  Fix For: 1.2 Family
>  Attachments: RewriteTag.java.diff, Rewritetag-use-action.patch, 
> struts-html-Rewrite-action.patch, struts-html.tld.diff, struts-html.xml.diff
>
> I know its late in the cycle, but hopefully this can be squeezed in...
> The "action" attribute was recently added to the html:link tag (thanks!), but 
> was not added to the html:rewrite tag.  Seems like a simple oversight to me.  
> I'll take a crack at a patch in a few days, but maybe someone else has time 
> to 
> make this enhancement quickly?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Resolved: (STR-1135) Add "action" attribute to

 [ http://issues.apache.org/struts/browse/STR-1135?page=all ]
 
David Evans resolved STR-1135:
--

Resolution: Fixed

> Add "action" attribute to 
> 
>
>  Key: STR-1135
>  URL: http://issues.apache.org/struts/browse/STR-1135
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: All
> Reporter: Jeff Butler
> Assignee: Ted Husted
> Priority: Minor
>  Fix For: 1.2 Family
>  Attachments: RewriteTag.java.diff, Rewritetag-use-action.patch, 
> struts-html-Rewrite-action.patch, struts-html.tld.diff, struts-html.xml.diff
>
> I know its late in the cycle, but hopefully this can be squeezed in...
> The "action" attribute was recently added to the html:link tag (thanks!), but 
> was not added to the html:rewrite tag.  Seems like a simple oversight to me.  
> I'll take a crack at a patch in a few days, but maybe someone else has time 
> to 
> make this enhancement quickly?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-1135) Add "action" attribute to

 [ http://issues.apache.org/struts/browse/STR-1135?page=all ]
 
David Evans closed STR-1135:



> Add "action" attribute to 
> 
>
>  Key: STR-1135
>  URL: http://issues.apache.org/struts/browse/STR-1135
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: All
> Reporter: Jeff Butler
> Assignee: Ted Husted
> Priority: Minor
>  Fix For: 1.2 Family
>  Attachments: RewriteTag.java.diff, Rewritetag-use-action.patch, 
> struts-html-Rewrite-action.patch, struts-html.tld.diff, struts-html.xml.diff
>
> I know its late in the cycle, but hopefully this can be squeezed in...
> The "action" attribute was recently added to the html:link tag (thanks!), but 
> was not added to the html:rewrite tag.  Seems like a simple oversight to me.  
> I'll take a crack at a patch in a few days, but maybe someone else has time 
> to 
> make this enhancement quickly?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-1288) Problem with resouce bundles when working with multiple modules

 [ http://issues.apache.org/struts/browse/STR-1288?page=all ]
 
David Evans reopened STR-1288:
--

Assign To: (was: Struts Developer Mailing List)

> Problem with resouce bundles when working with multiple modules
> ---
>
>  Key: STR-1288
>  URL: http://issues.apache.org/struts/browse/STR-1288
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: Unknown
>  Environment: Operating System: All
> Platform: PC
> Reporter: Guy Wens
>  Fix For: 1.2 Family

>
> ,  and  only work ok the first 
> time 
> called in a JSP page when using modules and when not explicitly specifying a 
> resouce bundle in the Tag attribute. When they are called twice in the same 
> page, the tags don't find the default bundle for the module the second time.
> Suppose we have a module "instruments":
> 
> ...
>   
> ...
>  
> ...
> 
> If the previous code is like follows it works:
> 
> ...
>   
> ...
>

[jira] Resolved: (STR-1288) Problem with resouce bundles when working with multiple modules

 [ http://issues.apache.org/struts/browse/STR-1288?page=all ]
 
David Evans resolved STR-1288:
--

Resolution: Duplicate

> Problem with resouce bundles when working with multiple modules
> ---
>
>  Key: STR-1288
>  URL: http://issues.apache.org/struts/browse/STR-1288
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: Unknown
>  Environment: Operating System: All
> Platform: PC
> Reporter: Guy Wens
>  Fix For: 1.2 Family

>
> ,  and  only work ok the first 
> time 
> called in a JSP page when using modules and when not explicitly specifying a 
> resouce bundle in the Tag attribute. When they are called twice in the same 
> page, the tags don't find the default bundle for the module the second time.
> Suppose we have a module "instruments":
> 
> ...
>   
> ...
>  
> ...
> 
> If the previous code is like follows it works:
> 
> ...
>   
> ...
>

[jira] Closed: (STR-1288) Problem with resouce bundles when working with multiple modules

 [ http://issues.apache.org/struts/browse/STR-1288?page=all ]
 
David Evans closed STR-1288:



> Problem with resouce bundles when working with multiple modules
> ---
>
>  Key: STR-1288
>  URL: http://issues.apache.org/struts/browse/STR-1288
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: Unknown
>  Environment: Operating System: All
> Platform: PC
> Reporter: Guy Wens
>  Fix For: 1.2 Family

>
> ,  and  only work ok the first 
> time 
> called in a JSP page when using modules and when not explicitly specifying a 
> resouce bundle in the Tag attribute. When they are called twice in the same 
> page, the tags don't find the default bundle for the module the second time.
> Suppose we have a module "instruments":
> 
> ...
>   
> ...
>  
> ...
> 
> If the previous code is like follows it works:
> 
> ...
>   
> ...
>

[jira] Reopened: (STR-1280) bean:message could be more power with little effort

 [ http://issues.apache.org/struts/browse/STR-1280?page=all ]
 
David Evans reopened STR-1280:
--

Assign To: (was: Struts Developer Mailing List)

> bean:message could be more power with little effort
> ---
>
>  Key: STR-1280
>  URL: http://issues.apache.org/struts/browse/STR-1280
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: 1.1 RC1
>  Environment: Operating System: All
> Platform: All
> Reporter: William A. McArthur, Jr
> Priority: Minor

>
> A lot of power in the bean:message taglib is lost because the setters/getters
> for the arg0 though arg4 take java.lang.String arguments instead of
> java.lang.Object. This is because it makes it impossible to pass a subclass of
> java.lang.Number as one of the arguments.
> For example if in my app's Message.properties I have the property:
> how.many.messages={0,choice,0#No messages|1#One message|1 and I use the bean:message taglib in the following way:
> "/>
> The java.text.ChoiceFormat fails in the method
> java.text.NumberFormat.format(Object,StringBuffer,FieldPosition) with a
> "java.lang.IllegalArgumentException: Cannot format given Object as a Number"
> because "12" is a string and not a subclass of Number.
> If I use the bean:message taglib in the following way:
> 
> The JSP fails to compile because there is no way to cast an Integer to a 
> String.
> I really wish it wasn't so but I understand it's probably too late in the game
> to get this change made by Struts 1.1. It would be nice that if in the
> documentation a note is added mentioning that the bean:message taglib only
> allows only very simplistic parametric replacement so people like myself don't
> assume we have access to the full power of java.text.MessageFormat and waste a
> few hours trying to figure out why things are breaking.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-1280) bean:message could be more power with little effort

 [ http://issues.apache.org/struts/browse/STR-1280?page=all ]
 
David Evans closed STR-1280:


Resolution: Won't Fix

> bean:message could be more power with little effort
> ---
>
>  Key: STR-1280
>  URL: http://issues.apache.org/struts/browse/STR-1280
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: 1.1 RC1
>  Environment: Operating System: All
> Platform: All
> Reporter: William A. McArthur, Jr
> Priority: Minor

>
> A lot of power in the bean:message taglib is lost because the setters/getters
> for the arg0 though arg4 take java.lang.String arguments instead of
> java.lang.Object. This is because it makes it impossible to pass a subclass of
> java.lang.Number as one of the arguments.
> For example if in my app's Message.properties I have the property:
> how.many.messages={0,choice,0#No messages|1#One message|1 and I use the bean:message taglib in the following way:
> "/>
> The java.text.ChoiceFormat fails in the method
> java.text.NumberFormat.format(Object,StringBuffer,FieldPosition) with a
> "java.lang.IllegalArgumentException: Cannot format given Object as a Number"
> because "12" is a string and not a subclass of Number.
> If I use the bean:message taglib in the following way:
> 
> The JSP fails to compile because there is no way to cast an Integer to a 
> String.
> I really wish it wasn't so but I understand it's probably too late in the game
> to get this change made by Struts 1.1. It would be nice that if in the
> documentation a note is added mentioning that the bean:message taglib only
> allows only very simplistic parametric replacement so people like myself don't
> assume we have access to the full power of java.text.MessageFormat and waste a
> few hours trying to figure out why things are breaking.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[Struts Wiki] Update of "RoughSpots" by Bob Lee

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change 
notification.

The following page has been changed by Bob Lee:
http://wiki.apache.org/struts/RoughSpots

--
 /${actionNamespace}
   
  }}}  My point is this feature enables a new style of development, one closer 
to RoR and, IMO, easier for the newbie, without affecting anyone else.
+ * [crazybob] Assuming you have a `getResult()` method and you've defined 
a global result, your second example could look like this: {{{
+  result = ActionRedirectResult("bar", "foo");
+  return CUSTOM;
+ }}} A Ruby on Rails analog would look like this: {{{
+   public void execute() {
+ ...
+ if (foo) {
+   redirectToAction("foo", "bar");
+ }
+ else {
+   forwardToAction("tee");
+ }
+   }
+ }}} If the user doesn't call a result method, we would use an intelligent 
default. You could implement this using an interceptor and an action support 
class. However, I'm with Jason: I've never needed this and I like the 
seperation.
  
  
  == Nice to haves ==

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

[jira] Reopened: (STR-737) ActionForward or tag does not support absolute URIs

 [ http://issues.apache.org/struts/browse/STR-737?page=all ]
 
David Evans reopened STR-737:
-

Assign To: David Graham  (was: David Graham)

> ActionForward or  tag does not support absolute URIs
> ---
>
>  Key: STR-737
>  URL: http://issues.apache.org/struts/browse/STR-737
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.1 Beta 3
>  Environment: Operating System: other
> Platform: Other
> Reporter: Ted Husted
> Assignee: David Graham
>  Fix For: 1.1 Family
>  Attachments: struts.jar, struts.jar
>
> The ActionForward is documented to support a path with a "Module-relative or 
> context-relative URI to which control should be forwarded, or an absolute or 
> relative URI to which control should be redirected." but absolute and 
> relative 
> URIs are both prefixed with the application context. See update to html-link 
> page in exercise-taglib.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-737) ActionForward or tag does not support absolute URIs

 [ http://issues.apache.org/struts/browse/STR-737?page=all ]
 
David Evans closed STR-737:
---

Resolution: Fixed

> ActionForward or  tag does not support absolute URIs
> ---
>
>  Key: STR-737
>  URL: http://issues.apache.org/struts/browse/STR-737
>  Project: Struts Action 1
> Type: Bug

>   Components: Taglibs
> Versions: 1.1 Beta 3
>  Environment: Operating System: other
> Platform: Other
> Reporter: Ted Husted
> Assignee: David Graham
>  Fix For: 1.1 Family
>  Attachments: struts.jar, struts.jar
>
> The ActionForward is documented to support a path with a "Module-relative or 
> context-relative URI to which control should be forwarded, or an absolute or 
> relative URI to which control should be redirected." but absolute and 
> relative 
> URIs are both prefixed with the application context. See update to html-link 
> page in exercise-taglib.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-301) OptionsTag.doEndTag -> calls method to populate selects twice

 [ http://issues.apache.org/struts/browse/STR-301?page=all ]
 
David Evans reopened STR-301:
-


> OptionsTag.doEndTag -> calls method to populate selects twice
> -
>
>  Key: STR-301
>  URL: http://issues.apache.org/struts/browse/STR-301
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: All
> Reporter: jduff
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.2.8

>
> When the logic falls into the section of code that uses "separate iterators"
> to render the options there is the potential that the getIterator() is
> called twice to get an iterator to the same list.  It is extremely 
> inefficient 
> in the sense that the underlying method that returns the collection for the
> iterator may have significant processing involved.  From a purists
> standpoint, in this situation, there is simply no reason to have to do this
> twice, regardless of the degree of inefficiency.  This could be corrected by 
> slightly modifying the code to use a combination of a flag
> and only one iterator as noted in the new code included in the bottom of this
> file...
> public int doEndTag() throws JspException {
> ...
>   if (collection != null) {
>   ...
>   else {
> // Construct iterators for the values and labels collections
> Iterator valuesIterator = getIterator(name, property);
> Iterator labelsIterator = null;
> boolean labels = false; 
> if ((labelName != null) || (labelProperty != null)) {
>   labels = true;
>   labelsIterator = getIterator(labelName, labelProperty);
> }
> // Render the options tags for each element of the values coll.
> while (valuesIterator.hasNext()) {
>   String value = valuesIterator.next().toString();
>   String label = value;
>   // Get the label values for each option
>   if (labels == true) {
> if (labelsIterator.hasNext()) {
>   label = labelsIterator.next().toString();
> }
>   } else {
> // if the label property was not specified the label will
> // be the same as the actual value for the option
> label = value;
>   }
>   addOption(sb, value, label, selectTag.isMatched(value));
> }
>   }
>   ...
> }
> Thanks.
> jason

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-301) OptionsTag.doEndTag -> calls method to populate selects twice

 [ http://issues.apache.org/struts/browse/STR-301?page=all ]
 
David Evans closed STR-301:
---

Resolution: Fixed

> OptionsTag.doEndTag -> calls method to populate selects twice
> -
>
>  Key: STR-301
>  URL: http://issues.apache.org/struts/browse/STR-301
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: All
> Reporter: jduff
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.2.8

>
> When the logic falls into the section of code that uses "separate iterators"
> to render the options there is the potential that the getIterator() is
> called twice to get an iterator to the same list.  It is extremely 
> inefficient 
> in the sense that the underlying method that returns the collection for the
> iterator may have significant processing involved.  From a purists
> standpoint, in this situation, there is simply no reason to have to do this
> twice, regardless of the degree of inefficiency.  This could be corrected by 
> slightly modifying the code to use a combination of a flag
> and only one iterator as noted in the new code included in the bottom of this
> file...
> public int doEndTag() throws JspException {
> ...
>   if (collection != null) {
>   ...
>   else {
> // Construct iterators for the values and labels collections
> Iterator valuesIterator = getIterator(name, property);
> Iterator labelsIterator = null;
> boolean labels = false; 
> if ((labelName != null) || (labelProperty != null)) {
>   labels = true;
>   labelsIterator = getIterator(labelName, labelProperty);
> }
> // Render the options tags for each element of the values coll.
> while (valuesIterator.hasNext()) {
>   String value = valuesIterator.next().toString();
>   String label = value;
>   // Get the label values for each option
>   if (labels == true) {
> if (labelsIterator.hasNext()) {
>   label = labelsIterator.next().toString();
> }
>   } else {
> // if the label property was not specified the label will
> // be the same as the actual value for the option
> label = value;
>   }
>   addOption(sb, value, label, selectTag.isMatched(value));
> }
>   }
>   ...
> }
> Thanks.
> jason

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Updated: (WW-1300) Unwanted locale-formatting of checkbox values

2006-04-27 Thread Anonymous (JIRA)

 [ http://issues.apache.org/struts/browse/WW-1300?page=all ]

 updated WW-1300:
-

Attachment: patch.txt

> Unwanted locale-formatting of checkbox values
> -
>
>  Key: WW-1300
>  URL: http://issues.apache.org/struts/browse/WW-1300
>  Project: Struts Action 2
> Type: Bug

>   Components: Views
> Versions: WW 2.2.2
>  Environment: Windows XP, FreeMarker for view
> Reporter: Dennis Doubleday
> Priority: Minor
>  Attachments: patch.txt
>
> See User Forum thread 
> http://forums.opensymphony.com/thread.jspa?threadID=28212&tstart=0 for 
> context.
> We are using a checkbox list like this:
> <@ww.checkboxlist label="Roles" name="roleIds" list="roleMap"/>
> The "roleMap" is a Map. The output of this is:
> 
> newrole
> 
> User
> 
> adminall
> Note that second one--the Long value gets written as "4,704". The comma 
> causes a conversion error when the form is submitted. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

tablib tests [was Re: closing and reopening jira issues]

2006-04-27 Thread James Mitchell

Speaking of taglib tests..Ted, I was chatting with Don yesterday  
and I mentioned an idea that someone had brought up a while back, and  
so I wanted to float it by you.


Do you remember the discussions about the taglib tests where it was  
proposed (sorry, don't remember who) that we use the taglib exercise  
web app both as a helpful tutorial and also as a way of testing?   
(reuse is always a good thing;)


With the move to Maven, the taglib tests were pretty much broken and  
neglected.  They were not neglected due to a lack of interest, but  
more for technical reasons (translated -- I didn't know how to force  
Maven to do what I wanted).


So, now here we are with Maven 2, and cactus testing doesn't seem to  
be any easier that with Maven 1 and so I am wondering if it isn't  
worth taking a look at that idea again.  I'd be willing (as I was  
back when I wrote the 1,000s of taglib tests) to do all the work on  
this.


Not sure which approach would be best, maybe I'll put together a  
proof of concept and send it around for comments.


What do you think?


--
James Mitchell




On Apr 27, 2006, at 1:18 PM, Ted Husted wrote:


On 4/27/06, Don Brown <[EMAIL PROTECTED]> wrote:
I like that, and if they don't close it by the release, the  
release manager will close it.


I don't understand why we should set this up so every ticket has to be
closed twice. The tickets are already subject to peer-review by the
PMC and all the subscribers to dev@ (or issues@). We have nightly
builds going out every day that reflect the changes made by the
tickets.

If the problem is fixed, then the release testing should prove that it
is fixed. I don't believe that we should be turing the release manager
into some type of clerical assistant or gatekeeper for the rest of us.
If the RM wants to review the tickets that have been closed since the
last relesae, that's fine. But I would suggest that we not try to dump
any additional responsibility on this role. It's a hard enough job as
it is.

My suggestion would be that whoever applies the patch should also
supply a test that proves the issue is resolved, and then closes the
ticket as fixed, until shown otherwise.  It doesn't have to be a fancy
test. In the case of a taglib, it could just be a use case in the
taglib exercise application.

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

[jira] Reopened: (STR-472) logic:iterate doesn't accept primitive values

 [ http://issues.apache.org/struts/browse/STR-472?page=all ]
 
David Evans reopened STR-472:
-

Assign To: Craig McClanahan  (was: Struts Developer Mailing List)

> logic:iterate doesn't accept primitive values
> -
>
>  Key: STR-472
>  URL: http://issues.apache.org/struts/browse/STR-472
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: All
> Reporter: Martin Rose
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family
>  Attachments: primitiveIterate.diff
>
> The struts logic:iterate tag doesn't except arrays of primitives to iterate 
> over.  I've included a relatively simple patch that allows this, and makes 
> the 
> logic:iterate tag much more intuitive and complete as it will handle 
> collections and arrays of anything appropriately.
> Could a person with access to the tree PLEASE COMMENT on this to me either 
> publically or privately, as I would like to do my best to see this included 
> in 
> the 1.1.x release.
> --- jakarta-struts-1.0.1-
> src/src/share/org/apache/struts/taglib/logic/IterateTag.java   Wed Jun 13 
> 22:24:28 2001
> +++ jakarta-struts-1.0.1-src-
> mfr/src/share/org/apache/struts/taglib/logic/IterateTag.java Thu Jan 31 
> 09:31:30 2002
> @@ -310,9 +310,15 @@
> // Construct an iterator for this collection
> -   if (collection.getClass().isArray())
> -   collection = Arrays.asList((Object[]) collection);
> -   if (collection instanceof Collection)
> +   if (collection.getClass().isArray()) {
> +   int length = java.lang.reflect.Array.getLength(collection);
> +   Collection c = new ArrayList();
> +   for(int i=0; i +   c.add(java.lang.reflect.Array.get(collection, i));
> +   }
> +   iterator = c.iterator();
> +   }
> +   else if (collection instanceof Collection)
> iterator = ((Collection) collection).iterator();
> else if (collection instanceof Iterator)
> iterator = (Iterator) collection;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-472) logic:iterate doesn't accept primitive values

 [ http://issues.apache.org/struts/browse/STR-472?page=all ]
 
David Evans closed STR-472:
---

Resolution: Fixed

> logic:iterate doesn't accept primitive values
> -
>
>  Key: STR-472
>  URL: http://issues.apache.org/struts/browse/STR-472
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Nightly Build
>  Environment: Operating System: All
> Platform: All
> Reporter: Martin Rose
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family
>  Attachments: primitiveIterate.diff
>
> The struts logic:iterate tag doesn't except arrays of primitives to iterate 
> over.  I've included a relatively simple patch that allows this, and makes 
> the 
> logic:iterate tag much more intuitive and complete as it will handle 
> collections and arrays of anything appropriately.
> Could a person with access to the tree PLEASE COMMENT on this to me either 
> publically or privately, as I would like to do my best to see this included 
> in 
> the 1.1.x release.
> --- jakarta-struts-1.0.1-
> src/src/share/org/apache/struts/taglib/logic/IterateTag.java   Wed Jun 13 
> 22:24:28 2001
> +++ jakarta-struts-1.0.1-src-
> mfr/src/share/org/apache/struts/taglib/logic/IterateTag.java Thu Jan 31 
> 09:31:30 2002
> @@ -310,9 +310,15 @@
> // Construct an iterator for this collection
> -   if (collection.getClass().isArray())
> -   collection = Arrays.asList((Object[]) collection);
> -   if (collection instanceof Collection)
> +   if (collection.getClass().isArray()) {
> +   int length = java.lang.reflect.Array.getLength(collection);
> +   Collection c = new ArrayList();
> +   for(int i=0; i +   c.add(java.lang.reflect.Array.get(collection, i));
> +   }
> +   iterator = c.iterator();
> +   }
> +   else if (collection instanceof Collection)
> iterator = ((Collection) collection).iterator();
> else if (collection instanceof Iterator)
> iterator = (Iterator) collection;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-407) Convert HTML Tags to be XHTML-compliant when

 [ http://issues.apache.org/struts/browse/STR-407?page=all ]
 
David Evans reopened STR-407:
-

Assign To: David Graham  (was: Struts Developer Mailing List)

> Convert HTML Tags to be XHTML-compliant when 
> -
>
>  Key: STR-407
>  URL: http://issues.apache.org/struts/browse/STR-407
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: Matt Raible
> Assignee: David Graham
> Priority: Minor
>  Fix For: 1.1 Family
>  Attachments: xhtml.patch
>
> When  is specified in a JSP, all child html elements 
> should be well-formed according to the XHTML 1.0 Specification.
> Just wanted to get this into Bugzilla ;)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-407) Convert HTML Tags to be XHTML-compliant when

 [ http://issues.apache.org/struts/browse/STR-407?page=all ]
 
David Evans closed STR-407:
---

Resolution: Fixed

> Convert HTML Tags to be XHTML-compliant when 
> -
>
>  Key: STR-407
>  URL: http://issues.apache.org/struts/browse/STR-407
>  Project: Struts Action 1
> Type: Improvement

>   Components: Taglibs
> Versions: Unknown
>  Environment: Operating System: other
> Platform: Other
> Reporter: Matt Raible
> Assignee: David Graham
> Priority: Minor
>  Fix For: 1.1 Family
>  Attachments: xhtml.patch
>
> When  is specified in a JSP, all child html elements 
> should be well-formed according to the XHTML 1.0 Specification.
> Just wanted to get this into Bugzilla ;)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-311) Need More Flexibility Setting/Getting ActionForm Properties

 [ http://issues.apache.org/struts/browse/STR-311?page=all ]
 
David Evans reopened STR-311:
-

Assign To: Craig McClanahan  (was: Struts Developer Mailing List)

> Need More Flexibility Setting/Getting ActionForm Properties
> ---
>
>  Key: STR-311
>  URL: http://issues.apache.org/struts/browse/STR-311
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.0 Final
>  Environment: Operating System: All
> Platform: All
> Reporter: Erik K. Worth
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family

>
> AltoWeb, Inc. would like to use the org.apache.struts.action.ActionForm as a 
> hash table of properties rather than a canonical bean.  A hash table approach 
> would be more efficient for us and we would not have to generate as much code 
> (the form beans).  The current Struts framework does not allow us to do this 
> without changing the code because the ActionForm is accessed and updated 
> using 
> static utility methods that we cannot overload or extend (e.g. RequestUtils, 
> PropertyUtils, BeanUtils).  
> At this point, it looks like it is relatively easy to populate the ActionForm 
> from a request by overloading the processPopulate method in the ActionServlet 
> class.  However, it is not easy to populate a servlet response because so 
> many 
> of the tags use the static getProperty method in BeanUtils to pull 
> information 
> from the ActionForm.  Therefore, we request some type of extension mechanism 
> that allows us to customize the way properties are accessed and mutated in 
> the 
> ActionForm.
> We would like to have a simple way to change this behavior without code 
> changes 
> to the struts code, or with limited code changes.
> Ideally, we thought of subclassing some classes or registering a class that 
> does the mapping to beans (what PropertyUtils does today). This way, we can 
> use 
> the struts code without changing it.
> It is possible to have one utility class that is loaded by the Servlet or the 
> web application by name to do all the mappings.
> Another way is to make sure that all the property settings go through one 
> class 
> that we can modify. In that case the changes to the struts code will be 
> limited 
> to one class only.
> It is possible to change the BeanUtil class behaviour today. We do not like 
> this approach, because this class is part of commons package and is not 
> directly part of struts. What this means is that other apache code (and our 
> code as well) might try to use this class. Therefore it is better that the 
> mapping is done by a single struts class that can delegate to the BeanUtils 
> class.
> So the options are:
> 1. Overloaded functions (does not require struts code modification)
> 2. Registered utility class (does not require struts code modification)
> 3. A single mapping class that delegates to BeanUtils (Requires one struts 
> class modification, does not require common libraries modification).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-311) Need More Flexibility Setting/Getting ActionForm Properties

 [ http://issues.apache.org/struts/browse/STR-311?page=all ]
 
David Evans closed STR-311:
---

Resolution: Fixed

> Need More Flexibility Setting/Getting ActionForm Properties
> ---
>
>  Key: STR-311
>  URL: http://issues.apache.org/struts/browse/STR-311
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.0 Final
>  Environment: Operating System: All
> Platform: All
> Reporter: Erik K. Worth
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family

>
> AltoWeb, Inc. would like to use the org.apache.struts.action.ActionForm as a 
> hash table of properties rather than a canonical bean.  A hash table approach 
> would be more efficient for us and we would not have to generate as much code 
> (the form beans).  The current Struts framework does not allow us to do this 
> without changing the code because the ActionForm is accessed and updated 
> using 
> static utility methods that we cannot overload or extend (e.g. RequestUtils, 
> PropertyUtils, BeanUtils).  
> At this point, it looks like it is relatively easy to populate the ActionForm 
> from a request by overloading the processPopulate method in the ActionServlet 
> class.  However, it is not easy to populate a servlet response because so 
> many 
> of the tags use the static getProperty method in BeanUtils to pull 
> information 
> from the ActionForm.  Therefore, we request some type of extension mechanism 
> that allows us to customize the way properties are accessed and mutated in 
> the 
> ActionForm.
> We would like to have a simple way to change this behavior without code 
> changes 
> to the struts code, or with limited code changes.
> Ideally, we thought of subclassing some classes or registering a class that 
> does the mapping to beans (what PropertyUtils does today). This way, we can 
> use 
> the struts code without changing it.
> It is possible to have one utility class that is loaded by the Servlet or the 
> web application by name to do all the mappings.
> Another way is to make sure that all the property settings go through one 
> class 
> that we can modify. In that case the changes to the struts code will be 
> limited 
> to one class only.
> It is possible to change the BeanUtil class behaviour today. We do not like 
> this approach, because this class is part of commons package and is not 
> directly part of struts. What this means is that other apache code (and our 
> code as well) might try to use this class. Therefore it is better that the 
> mapping is done by a single struts class that can delegate to the BeanUtils 
> class.
> So the options are:
> 1. Overloaded functions (does not require struts code modification)
> 2. Registered utility class (does not require struts code modification)
> 3. A single mapping class that delegates to BeanUtils (Requires one struts 
> class modification, does not require common libraries modification).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Reopened: (STR-561) Need to update the Actions in the actions package for 1.1

 [ http://issues.apache.org/struts/browse/STR-561?page=all ]
 
David Evans reopened STR-561:
-

Assign To: Craig McClanahan  (was: Struts Developer Mailing List)

> Need to update the Actions in the actions package for 1.1
> -
>
>  Key: STR-561
>  URL: http://issues.apache.org/struts/browse/STR-561
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.1 Beta 1
>  Environment: Operating System: other
> Platform: Other
> Reporter: Chuck Cavaness
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family
>  Attachments: Action.java.patch
>
> The Action classes defined in the org.apache.struts.actions package need to 
> be 
> updated to reflect the changes in 1.1.
> These classes still use the perform() method, but more importantly, still 
> throw 
> ServletException and IOException, unlike the new execute() method, which only 
> throws Exception.
> Definitely not a huge priority, but nonetheless important for new users to 
> get 
> some consistency.
> Chuck

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

[jira] Closed: (STR-561) Need to update the Actions in the actions package for 1.1

 [ http://issues.apache.org/struts/browse/STR-561?page=all ]
 
David Evans closed STR-561:
---

Resolution: Fixed

> Need to update the Actions in the actions package for 1.1
> -
>
>  Key: STR-561
>  URL: http://issues.apache.org/struts/browse/STR-561
>  Project: Struts Action 1
> Type: Improvement

>   Components: Extras
> Versions: 1.1 Beta 1
>  Environment: Operating System: other
> Platform: Other
> Reporter: Chuck Cavaness
> Assignee: Craig McClanahan
> Priority: Minor
>  Fix For: 1.1 Family
>  Attachments: Action.java.patch
>
> The Action classes defined in the org.apache.struts.actions package need to 
> be 
> updated to reflect the changes in 1.1.
> These classes still use the perform() method, but more importantly, still 
> throw 
> ServletException and IOException, unlike the new execute() method, which only 
> throws Exception.
> Definitely not a huge priority, but nonetheless important for new users to 
> get 
> some consistency.
> Chuck

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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

svn commit: r397603 - in /struts/action/trunk/el: pom.xml src/main/

Author: jmitchell
Date: Thu Apr 27 11:42:55 2006
New Revision: 397603

URL: http://svn.apache.org/viewcvs?rev=397603&view=rev
Log:
making action1 src consistent (repository details only)

Added:
struts/action/trunk/el/src/main/
Modified:
struts/action/trunk/el/pom.xml

Modified: struts/action/trunk/el/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/el/pom.xml?rev=397603&r1=397602&r2=397603&view=diff
==
--- struts/action/trunk/el/pom.xml (original)
+++ struts/action/trunk/el/pom.xml Thu Apr 27 11:42:55 2006
@@ -19,8 +19,9 @@
  */
 -->
 
-http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
-  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
+http://maven.apache.org/POM/4.0.0";
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
 

   org.apache.struts.action
@@ -54,13 +55,6 @@
**/*.tld
 
 META-INF/tlds
- 
- 
-../build
-
-   LICENSE.txt
-   NOTICE.txt
-
  
   
 



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

svn commit: r397604 - in /struts/action/trunk/el: pom.xml src/java/ src/main/java/ src/main/resources/

Author: jmitchell
Date: Thu Apr 27 11:46:37 2006
New Revision: 397604

URL: http://svn.apache.org/viewcvs?rev=397604&view=rev
Log:
making action1 src consistent (repository details only)

Added:
struts/action/trunk/el/src/main/java/
  - copied from r397591, struts/action/trunk/el/src/java/
struts/action/trunk/el/src/main/resources/
Removed:
struts/action/trunk/el/src/java/
Modified:
struts/action/trunk/el/pom.xml

Modified: struts/action/trunk/el/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/el/pom.xml?rev=397604&r1=397603&r2=397604&view=diff
==
--- struts/action/trunk/el/pom.xml (original)
+++ struts/action/trunk/el/pom.xml Thu Apr 27 11:46:37 2006
@@ -44,10 +44,6 @@

 

-
-  src/java
-  
-
   
  
 src/tld



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

Re: Proposal for change

2006-04-27 Thread Jonathan Revusky


Daniel Warner wrote:

On 4/27/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote:


Dakota Jack wrote:


Doesn't this kind of talk sound goofy to you all?  Isn't this reference to
the Apache Way sort of like a secret handshake and a silly hat?


It's all that, yes, but it's also not very honest, I'd say.

You see, the various scripture on the so-called "Apache Way" claims that
the ASF is run as a "meritocracy". What you see here is that the Struts
committers, after years of not achieving much, have invited in the
Webwork people with the intention of relabelling Webwork as Struts
Action 2 (when the existing Struts codebase is Struts Action 1). They
tacitly accept that the Webwork people ran the better project
technically, did the better work.

Well, once you accept that the other people did the better work, and you
have a meritocracy, then those other people, who have more merit, they
run the show.

The logic of this looks unassailble to me.



That's because you don't understand what you're talking about. 





The
"meritocracy" idea at Apache is not about who does the work best. 
It's just about who does the work.  You do the work, you make

decisions.




You're joking, aren't you, Daniel? You're saying this is a "meritocracy" 
in which you gain merit by doing work, but the quality of the work 
doesn't matter?


OMG... I think maybe you're serious...

Well, that's just ridiculous, isn't it C'mon...




So, by what basic principle does the existing Struts PMC remain in
control of the project when they accept that the other people did better
work?

The only principle I see is the principle of incumbency or tenure.



That's a problem with your vision.  There are plenty of reasons:

1) it's more about doing the work than doing the work "better".


No further comment.



2) SAF 2/WebWork is still in incubation.  It's not even actually part
of Struts yet.




The "incubator" is just ASF pseudoreality. It doesn't correspond to 
anything real. It makes no sense in this context. An actual incubator is 
something you use to hatch eggs, or sometimes it refers to a kind of 
environment that prematurely born babies are put in, because they could 
not survive in the outside world yet.


The living entity that you incubate is not even an infant, it is 
something in an embryonic state. Talking about how Webwork is still in 
"incubation" does not reflect anything real, because Webwork is not an 
unborn baby or even an infant. It is the moral equivalent of an adult, a 
peer of the Struts project and other projects in its space.


This whole business of mature projects like Webwork being "incubated" is 
just yet another striking example of the kind of bizarre use of words 
that is resorted to when people talk about this so-called "Apache Way".


The "incubator" is like the "meritocracy". Even though the term is being 
used as a kind of analogy, it does such violence to the normal meaning 
of the English word that it's hard to even have a sensible conversation 
about it.



3) The Struts PMC currently oversees Shale, Tiles, and SAF 1.  WebWork
is not the only project here.


Until recently, SAF 1 was simply what was called "Struts". The status of 
the Struts developers is based on the existence of that codebase.


My point was that, when they accept that Webwork is simply better, as 
evidenced by calling it SAF 2, when Struts itself is SAF 1, this means 
that the Webwork people did superior work.


People who did inferior work overseeing or managing the people who did 
the better work, does not, prima facie, correspond to the basic logic 
and structure of what anybody would call a meritocracy.






When people who did inferior work remain the managers of a project (and
ostensibly manage the people who did the better work) and this is by
virtue of incumbency or tenure, you don't have a meritocracy.



And all you have is a strawman.  Pay attention to how things actually
are run around here. 


I've been watching.

The PMC doesn't "manage" other committers.  


Maybe they don't. However, I think the 'M' in PMC stands for 
"management". But okay, the PMC doesn't actually do any managing, the 
incubator doesn't do anything that anybody sensible would call 
"incubating". The "merit" in the meritocracy has nothing to do with the 
quality of anybody's work...


Fine, be my guest

Really, when people accuse one of not understanding the "Apache Way", it 
may be a kind of compliment. Frankly, I would be automatically quite 
suspicious of anybody who asserts that they really understand all this 
stuff. Now, okay, the projects that want to get branded as Apache 
projects, the people involved have to demonstrate that they "get" this 
Apache Way, but that's more like having to agree with some lunatics 
because it's the easier path.


"Yeah, I get it, I really dig the Apache Way. Cripes, I don't know how 
we actually developed all this code we developed outside ASF when we 
didn't even have the Apache Way, though somehow we did. Bu

svn commit: r397605 - in /struts/action/trunk/el: pom.xml src/test/

Author: jmitchell
Date: Thu Apr 27 11:50:04 2006
New Revision: 397605

URL: http://svn.apache.org/viewcvs?rev=397605&view=rev
Log:
making action1 src consistent (repository details only)

Added:
struts/action/trunk/el/src/test/
Modified:
struts/action/trunk/el/pom.xml

Modified: struts/action/trunk/el/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/el/pom.xml?rev=397605&r1=397604&r2=397605&view=diff
==
--- struts/action/trunk/el/pom.xml (original)
+++ struts/action/trunk/el/pom.xml Thu Apr 27 11:50:04 2006
@@ -25,7 +25,7 @@
 

   org.apache.struts.action
-  struts-action-parent
+  struts-core
   1.3.3-SNAPSHOT

 



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

svn commit: r397606 - /struts/action/trunk/el/src/test/java/

Author: jmitchell
Date: Thu Apr 27 11:50:22 2006
New Revision: 397606

URL: http://svn.apache.org/viewcvs?rev=397606&view=rev
Log:
making action1 src consistent (repository details only)

Added:
struts/action/trunk/el/src/test/java/


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

svn commit: r397607 - /struts/action/trunk/el/src/main/resources/META-INF/

Author: jmitchell
Date: Thu Apr 27 11:52:49 2006
New Revision: 397607

URL: http://svn.apache.org/viewcvs?rev=397607&view=rev
Log:
making action1 src consistent (repository details only)

Added:
struts/action/trunk/el/src/main/resources/META-INF/


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

svn commit: r397608 - in /struts/action/trunk/el/src: main/resources/META-INF/tld/ tld/

Author: jmitchell
Date: Thu Apr 27 11:53:16 2006
New Revision: 397608

URL: http://svn.apache.org/viewcvs?rev=397608&view=rev
Log:
making action1 src consistent (repository details only)

Added:
struts/action/trunk/el/src/main/resources/META-INF/tld/
  - copied from r397591, struts/action/trunk/el/src/tld/
Removed:
struts/action/trunk/el/src/tld/


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

svn commit: r397609 - /struts/action/trunk/el/pom.xml

Author: jmitchell
Date: Thu Apr 27 11:54:48 2006
New Revision: 397609

URL: http://svn.apache.org/viewcvs?rev=397609&view=rev
Log:
making action1 src consistent (repository details only)

Modified:
struts/action/trunk/el/pom.xml

Modified: struts/action/trunk/el/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/el/pom.xml?rev=397609&r1=397608&r2=397609&view=diff
==
--- struts/action/trunk/el/pom.xml (original)
+++ struts/action/trunk/el/pom.xml Thu Apr 27 11:54:48 2006
@@ -121,7 +121,7 @@
 net.sourceforge.maven-taglib
 maven-taglib-plugin
 
-   ${basedir}/src/tld
+   
${basedir}/src/main/resources/META-INF/tld
 
  
   



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

svn commit: r397610 - /struts/action/trunk/el/pom.xml

Author: jmitchell
Date: Thu Apr 27 11:57:46 2006
New Revision: 397610

URL: http://svn.apache.org/viewcvs?rev=397610&view=rev
Log:
bad idea, (dependency issues) so reverting back

Modified:
struts/action/trunk/el/pom.xml

Modified: struts/action/trunk/el/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/el/pom.xml?rev=397610&r1=397609&r2=397610&view=diff
==
--- struts/action/trunk/el/pom.xml (original)
+++ struts/action/trunk/el/pom.xml Thu Apr 27 11:57:46 2006
@@ -25,7 +25,7 @@
 

   org.apache.struts.action
-  struts-core
+  struts-action-parent
   1.3.3-SNAPSHOT

 



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

svn commit: r397611 - /incubator/webwork2/action/src/main/java/org/apache/struts/action2/components/Tree.java

2006-04-27 Thread jcarreira

Author: jcarreira
Date: Thu Apr 27 11:59:25 2006
New Revision: 397611

URL: http://svn.apache.org/viewcvs?rev=397611&view=rev
Log:
Removing eplus copyright notice which was accidentally automatically added by 
an IDEA plugin

Modified:

incubator/webwork2/action/src/main/java/org/apache/struts/action2/components/Tree.java

Modified: 
incubator/webwork2/action/src/main/java/org/apache/struts/action2/components/Tree.java
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/action/src/main/java/org/apache/struts/action2/components/Tree.java?rev=397611&r1=397610&r2=397611&view=diff
==
--- 
incubator/webwork2/action/src/main/java/org/apache/struts/action2/components/Tree.java
 (original)
+++ 
incubator/webwork2/action/src/main/java/org/apache/struts/action2/components/Tree.java
 Thu Apr 27 11:59:25 2006
@@ -1,6 +1,3 @@
-/*
- * Copyright (c) 2005 ePlus Corporation. All Rights Reserved.
- */
 package org.apache.struts.action2.components;
 
 import com.opensymphony.xwork.util.OgnlValueStack;



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

Re: Bearing down on Struts Action 1.3.2

2006-04-27 Thread Angelo zerr

Hello;
I mail you to announce JSPTabControl project is created.

JSPTabControl is JSP taglib for manage tabs in your JSP. This taglib
generate tabs with "pure CSS tabs" technique (using "li" and "ul").
JSPtabControl give you several features :
1. tab control (body and header) and tab page (body and header) can be
easily customized with CSS.
2. titles of tab header page can be localized, by using Struts
AplicationResources or Resource Bundle file properties.
3. select a tab with JAVA code (for example in your action struts).
4. keep last tab selected after posting form.
5. set a state (INVISIBLE, READ-ONLY, FORBIDDEN, ERROR, ...) with JAVA code
for a particulary tab page :
5.1. to manage render of tab page (header and body) by using CSS.
5.2. to execute function javascript swith events (eg : when tab page has
FORBIDDEN state, you could execute javascrit message alert "You are not
authorized to access this tab!" when user click in this tab page).
You can manage any states. States are configurate (Style class and
Javascript to execute) into XML file.
 States can be used for exemple to manage role in your WEB Application.
6. use EL syntax (see JSTL specification) in JSPTabControl attributes taglib
(with, height,...) to evaluate JSP expressions dynamically.

You can find JSPTabControl  WEB site at
http://jsptabcontrol.sourceforge.net/ and download it at
http://sourceforge.net/project/showfiles.php?group_id=161371

Regards Angelo

Tea Time with the Trolls (Was: Re: Proposal for change)

I think I see a pattern here.  Put a short email in favor of Apache to
Jonathan, and you get a huge one in return.  The more you try to
actually argue with his points, the longer and more condescending the
response.  It is almost like free energy!  Someone ought to invent a
power station to harness this amazing source of energy and time so
that it is not a total waste any more!  Hmm.  I wonder if agreeing
with him will reduce his response or perhaps even give me the last
word!  Would that be a first?  Let's give it a go:

On 4/27/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote:
> Daniel Warner wrote:
> > The
> > "meritocracy" idea at Apache is not about who does the work best.
> > It's just about who does the work.  You do the work, you make
> > decisions.
>
> You're joking, aren't you, Daniel? You're saying this is a "meritocracy"
> in which you gain merit by doing work, but the quality of the work
> doesn't matter?
>
> Well, that's just ridiculous, isn't it C'mon...

You are right.  It is ridiculous to say that the quality of the work
does not matter.  Did i really say that?  Well, if you think that is
what I said, you must be correct.  OMG What could I have been
thinking? 

> > 2) SAF 2/WebWork is still in incubation.  It's not even actually part
> > of Struts yet.
>
> The "incubator" is just ASF pseudoreality. It doesn't correspond to
> anything real. It makes no sense in this context. An actual incubator is
> something you use to hatch eggs, or sometimes it refers to a kind of
> environment that prematurely born babies are put in, because they could
> not survive in the outside world yet.
>
> The living entity that you incubate is not even an infant, it is
> something in an embryonic state. Talking about how Webwork is still in
> "incubation" does not reflect anything real, because Webwork is not an
> unborn baby or even an infant. It is the moral equivalent of an adult, a
> peer of the Struts project and other projects in its space.
>
> This whole business of mature projects like Webwork being "incubated" is
> just yet another striking example of the kind of bizarre use of words
> that is resorted to when people talk about this so-called "Apache Way".
>
> The "incubator" is like the "meritocracy". Even though the term is being
> used as a kind of analogy, it does such violence to the normal meaning
> of the English word that it's hard to even have a sensible conversation
> about it.

I think you are on to something here.  Please help us find better
words and ways to use them in describing these things.  Then we can
avoid wasting time in all these silly semantic debates.

...
> People who did inferior work overseeing or managing the people who did
> the better work, does not, prima facie, correspond to the basic logic
> and structure of what anybody would call a meritocracy.

"Anybody" is a bit strong given our conversation above, but I see
nothing else inaccurate in this paragraph.  In fact, I would go
further and say that those do not even correspond upon second or third
examination either.

> Really, when people accuse one of not understanding the "Apache Way", it
> may be a kind of compliment. Frankly, I would be automatically quite
> suspicious of anybody who asserts that they really understand all this
> stuff. Now, okay, the projects that want to get branded as Apache
> projects, the people involved have to demonstrate that they "get" this
> Apache Way, but that's more like having to agree with some lunatics
> because it's the easier path.
>
> "Yeah, I get it, I really dig the Apache Way. Cripes, I don't know how
> we actually developed all this code we developed outside ASF when we
> didn't even have the Apache Way, though somehow we did. But now I see
> the error of our ways. Yessah, I see the light."
>
> "Praise be the Lawd! Hallelujah!"

Are you saying that people who like the Apache way of doing things are
all crazy zealots about it and believe that none of this code would
have developed without it?  Well, it is a good thing you are so well
known for being a rigorously logical debater, otherwise I would
suspect this was just biased and illogical mocking.   I know better
than that though.  You are right on the money, and now I realize I
have been suckered by this whole Apache thing.  It hasn't been useful
or productive at all.  In fact, it has held back the development of
what could have been great code and will surely corrupt the pure and
beautiful WebWork code.

> > Oh, and i seem to recall reading once in a Jakarta discussion that the
> > ideal situation to the ASF is if all committers for a project are on
> > the PMC that oversees the project.  Does that sound like it has
> > anything to do with who does better work? hmm.
>
> I dunno, but it doesn't have anything to do with what is happening in
> Struts, because in Struts, not all the committers are in the PMC...

Oh, but that seems inevitable for all those that stay here and stay
involved.  They too will be assimilated and begin

Dear trolls...

2006-04-27 Thread Patrick Lightbody

Dear trolls,
Please go. Or at least try to form your rambling in to some sort of actionable 
suggestion. But don't just bitch for the sake of knowing that people are 
reading, because...

Dear everyone else,
Please stop reading or replying to the trolls. Seriously. You guys are just as 
bad for feeding the trolls. Ignoring them is the fastest way to make them go 
away. I have not and will not entertain them with any sort of response. I 
suggest you do the same.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=28320&messageID=55091#55091


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

svn commit: r397633 - in /incubator/webwork2/uber: pom.xml src/assemble/main.xml

2006-04-27 Thread plightbo

Author: plightbo
Date: Thu Apr 27 14:00:52 2006
New Revision: 397633

URL: http://svn.apache.org/viewcvs?rev=397633&view=rev
Log:
assembly stuff

Modified:
incubator/webwork2/uber/pom.xml
incubator/webwork2/uber/src/assemble/main.xml

Modified: incubator/webwork2/uber/pom.xml
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/uber/pom.xml?rev=397633&r1=397632&r2=397633&view=diff
==
--- incubator/webwork2/uber/pom.xml (original)
+++ incubator/webwork2/uber/pom.xml Thu Apr 27 14:00:52 2006
@@ -12,26 +12,25 @@
 pom
 Uber Jar
 
-  
-
-  org.apache.maven.plugins
-  maven-assembly-plugin
-  
-src/assemble/main.xml
-  
-  
-  
-
-  
+
 
 
 

Modified: incubator/webwork2/uber/src/assemble/main.xml
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/uber/src/assemble/main.xml?rev=397633&r1=397632&r2=397633&view=diff
==
--- incubator/webwork2/uber/src/assemble/main.xml (original)
+++ incubator/webwork2/uber/src/assemble/main.xml Thu Apr 27 14:00:52 2006
@@ -8,6 +8,7 @@
   /
   
   org.apache.struts.action2:action
+  org.apache.struts.action2:action-api
   org.apache.struts.action2:action-jasperreports
   org.apache.struts.action2:action-jfreechart
   org.apache.struts.action2:action-pell-file-upload



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

svn commit: r397636 - /incubator/webwork2/project.iws

2006-04-27 Thread plightbo

Author: plightbo
Date: Thu Apr 27 14:09:46 2006
New Revision: 397636

URL: http://svn.apache.org/viewcvs?rev=397636&view=rev
Log:
whoops, this shouldn't have been checked in

Removed:
incubator/webwork2/project.iws


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

svn commit: r397638 - /incubator/webwork2/src/main/idea/project.xml

2006-04-27 Thread plightbo

Author: plightbo
Date: Thu Apr 27 14:11:09 2006
New Revision: 397638

URL: http://svn.apache.org/viewcvs?rev=397638&view=rev
Log:
code style

Added:
incubator/webwork2/src/main/idea/project.xml

Added: incubator/webwork2/src/main/idea/project.xml
URL: 
http://svn.apache.org/viewcvs/incubator/webwork2/src/main/idea/project.xml?rev=397638&view=auto
==
--- incubator/webwork2/src/main/idea/project.xml (added)
+++ incubator/webwork2/src/main/idea/project.xml Thu Apr 27 14:11:09 2006
@@ -0,0 +1,14 @@
+
+
+  
+
+
+  
+  
+
+  
+
+
+  
+
+



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

Re: Dear trolls...