date:20051129

On 11/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: craigmcc
> Date: Tue Nov 29 19:40:19 2005
> New Revision: 349871
>
> URL: http://svn.apache.org/viewcvs?rev=349871&view=rev
> Log:
> Take note of an outstanding serializability issue (37707), plus clean up
> some cosmetic details.
>
> Modified:
>struts/shale/trunk/docs/release-notes-1.0.0.html
>


Would you like to note 37571 [1] in the release notes as well? I
resolved it to LATER as soon as I opened it, but IMO, it will help to
"educate" Shale 1.0.0 users about it.

-Rahul

[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37571

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

Re: [shale][clay] Serializability (was Re: [shale] Import statements)

On 11/29/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 11/29/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> >

> In general, here's the policy that I propose to follow w.r.t. serialization:
>
> * Any class for which an instance might get stored (by the framework,
>  or by the application with the blessing of framework documentation
>  that says to do so) must be serializable.
>
> * Any class that is not serializable should not claim that it
>  "implements Serializable".
>


Indeed.


> That being said, let's review the cases:
>

>
> * CommonsValidator
>
>
> This is a JSF Validator, so it could well be attached to a UIComponent
> stored in session scope.  It's not obvious from a static review of the code
> what's the problem, but if there is one it'll need to be fixed.
>

> * StatusImpl
>
>
> Absolutely has to be serializable -- it's probably the non-static
> non-transient Log instance here.
>


Actually, both classes have declared fields that are non-serializable
interface types, rather than the serializable implementations of those
interfaces (this is probably a candidate to deviate from the Java best
practice of "coding to an interface" given the fields are private
implementation details hidden from the class' public contract). And
the logs.

I'll take a stab at these two in a few days, since there is already
consensus about the need to resolve these, and earlier this evening, I
told Niall I'd look at similar issues in [resources] anyway.


>
> > Digging into [chain], I found a related commit message on top of
> > ContextBase [1]. Were there any further developments on that? Seems
> > like it may be required to allow subclass implementors (of the base
> > impls in chain) to make their own decisions about serializability to
> > liberate the *WebContext classes, but that probably won't fit a minor
> > release (I'm not even sure if one is planned for [chain]).
>
>
> It's not obvious what we should do here ... but it's also not a decision we
> (Shale developers) or even we (Struts developers) can make in a vacuum.
> Needs to be addressed on commons-dev so any other stakeholders who care can
> pitch in an opinion.
>


Will move this bit to commons-dev when I get a chance.

-Rahul


>
> -Rahul
>
>
> Craig
>
>
> [1]
> > http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/impl/ContextBase.java
> >

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

Re: [ANNOUNCEMENT][shale] Struts Shale 1.0.0 Release Candidate 1 Available

On 11/28/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 11/28/05, Sean Schofield <[EMAIL PROTECTED]> wrote:

> >
> > A few questions.  For these interim builds that don't get released
> > officially.  I assume these builds aren't in the apache archive or
> > Maven repository right?  You just make them in the nightly dir or
> > something for people to evaluate?  Also, for bug reporting do you
> > recommend a verison number for each interim release?
>
> Ah, well, it's not an "interim" release. It's a release that we have
> graded test, Alpha, Beta, or GA.
>
> Initially, we make the build available in a committer's home directory
> or in the usual download directory, but we do not announce it the user
> list or submit it for mirroring until there is a quality vote. The
> ones that make it past the test-build stage go into the archive, just
> like most betas and rcs.
>
> * http://archive.apache.org/dist/struts/
>

Since I couldn't find the relevant thread(s) in the archives - What is
the intent behind not announcing on the user list? Avoiding potential
for confusion? If one goes by the premise that users are (a very
important part of) the development community, and arguably the only
"true" evaluators of the quality of your code, it would suggest that a
heads up on the user list *before* an upcoming quality vote is quite
appropriate?

Sure, it might generate some amount of noise, but some feedback will
inevitably be useful and no one -- not even HTTPD -- can claim that
cutting a release / test build is unobtrusive for the RM ;-)

For example, the most recent RC in Commons is receiving feedback from
users (even *potential* users, like me). Ofcourse, this is orthogonal
to RC vs grade vote, it is not my intent to revisit that.

-Rahul

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

[PROPOSAL] Target tickets to milestones and use as roadmap

I propose we use an automated, easy to understand roadmap that relies on 
Bugzilla tickets marked against Milestones.


With all the action in the Struts project lately, it is hard to see what 
is going on where, and specifically, qualitatively how much work remains 
before a Milestone will be reached.  We need a system that makes it easy 
to see at a glance the roadmap of each Struts subproject, and guide new 
contributions.


I see the solution involving the following:
 1. All tickets, bugs and enhancements, should be marked against a 
Milestone if accepted
 2. Any major feature or bug fix committed to svn should have a ticket 
and be assigned to a milestone.
 3. A ticket should only be marked against a Milestone if a developer 
has committed to work on it
 4. Once all the all the tickets against a Milestone have been 
resolved, the release is ready to be rolled.


The public face of this solution will be automated roadmap pages, which 
will be generated from Bugzilla reports.  These pages will show, at a 
glance, the status of each subproject, its milestones, and current 
progress toward reaching them.


I've developed a Java console app, driven by a cron, which screen 
scrapes Bugzilla reports to generate a roadmap [1].  As you can see from 
the demo, we don't currently use milestones much at all.  The roadmap is 
an idea taken from Trac [2] and I've personally have had great success 
with this approach of organizing Milestones.


Comments?

Don

[1] http://www.twdata.org/dakine/roadmap/action.html
[2] http://www.edgewall.com/trac/

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

svn commit: r349894 - /struts/build/trunk/KEYS

2005-11-29 Thread craigmcc

Author: craigmcc
Date: Tue Nov 29 22:29:09 2005
New Revision: 349894

URL: http://svn.apache.org/viewcvs?rev=349894&view=rev
Log:
Add my key as well.

Modified:
struts/build/trunk/KEYS

Modified: struts/build/trunk/KEYS
URL: 
http://svn.apache.org/viewcvs/struts/build/trunk/KEYS?rev=349894&r1=349893&r2=349894&view=diff
==
--- struts/build/trunk/KEYS (original)
+++ struts/build/trunk/KEYS Tue Nov 29 22:29:09 2005
@@ -145,3 +145,62 @@
 bAMAniQ+3a5yjxqf2k73+ipTq+VlSvfz
 =4ydx
 -END PGP PUBLIC KEY BLOCK-
+pub  1024D/02B78580 2004-03-06 Craig McClanahan (Apache Software Foundation) 
<[EMAIL PROTECTED]>
+sig 3   02B78580 2004-03-06   Craig McClanahan (Apache Software 
Foundation) <[EMAIL PROTECTED]>
+sub  2048g/A371884F 2004-03-06
+sig 02B78580 2004-03-06   Craig McClanahan (Apache Software 
Foundation) <[EMAIL PROTECTED]>
+
+pub  1024D/EB62A9D5 2005-11-30 Craig R. McClanahan <[EMAIL PROTECTED]>
+sig 3   EB62A9D5 2005-11-30   Craig R. McClanahan <[EMAIL PROTECTED]>
+sub  1024g/F8FB8E72 2005-11-30
+sig EB62A9D5 2005-11-30   Craig R. McClanahan <[EMAIL PROTECTED]>
+
+-BEGIN PGP PUBLIC KEY BLOCK-
+Version: GnuPG v1.2.1 (GNU/Linux)
+
+mQGiBEBKZE4RBADRTXrnpFTt2qydqf3DexgI32mWYbbOIYBQzfSUPEujvRx3gX7A
+PdJB1C4BQCsS5GI1gCUVRbXqV9gFdVeybwmd7HuOyf3pbA/3De8B9XW9+YDKkzf8
+2hXH9B5MQKhz6Da/ATRtSRx7UuJO6u+a/49so9zh3W4Mq3aTl/6WbzFdJwCgorMS
+uhjd54SNq7wRS2OSMSrRMo8EAK6DoZERz9JHl95uPSWBnNwXjZWRYSqYL87Z+5+Q
+WpSOx/6FBM3LZKXLhgm8HLg4Nwf2NF9PJXS8lOHgSy7iraIxVT2+3B3P7mU/IGnV
+GluagYhX3PV68y/fNEgT6Q2rkPoLGo/mL7KRy/KCw6sMNj7P9xS8vfukNRlAzPLp
+komXA/0aGrZDEqxOM8Tlx3tqb3IL4ciGpgs0C6f9pirxiZFWEI+FAuJEMbBZ6X9Z
+Mp22r9OteaGy8HKeAIT+TQZivOAuy+agE+FpW11D8XfZs0VjEu+67wagmTQr9aga
+e3gRe5AQWOuLWamS3wyTqdJHLp5/oZRuwVe/Pb1+bsMLMNWMu7RDQ3JhaWcgTWND
+bGFuYWhhbiAoQXBhY2hlIFNvZnR3YXJlIEZvdW5kYXRpb24pIDxjcmFpZ21jY0Bh
+cGFjaGUub3JnPohZBBMRAgAZBQJASmROBAsHAwIDFQIDAxYCAQIeAQIXgAAKCRDD
+LP5SAreFgIXMAJ0bYRscyN1S932WXKF1BnU1KurFRACgnFST9WYeZFnXWpRDjwwR
+OdYl/lC5Ag0EQEpkcBAIAPJ+MCPsfp9imyn6izJpc5mj++iTSkU5NMbCCfAD8gDf
+nfvWJj27s9TDGo+yXx6uFW4wAePNta/fcVlEoo4A8Twpok2si2ZKLJeSMNSMz0yi
+ikMTbB/QlSI4J0B8vf8v+ACKiSAZo2QnlIb+91OAM+NajLz3MWkg2XkIyTiNSqiT
+k7ZIDgB4XONU2sYNHIXoBTrKdF1NfbnW0NazLYZBxEmsDN97rd8iWyPi1lpT0Nza
+3CB/mcE8p43YF+1IXIRMPi1NtEO4qpUJauKVMhXgNUGCLAhbchq1wOlw1mH2jD3O
+y0WlxY4WilAFrEYWNgB6yhMKGeoeSRyzaPCks8C/HOcABAsH/RCFsiV5uGXu/O+P
+/0Trq+JAkexwMqLi5MXGEkmg7JmxpGu983MEMDcSaHTX8vRxURi/fTsegtsbtINA
+yoin1yrK4b/ow3IVrOwf949blje4LwUdgKuI4/tvlkry5ZsGjzOOkonGQZRIhSvH
+K+0ENdvZ7ZoNOMRjj/7FPBybuKqJEekFKgPi1DyAecehp4ftuWytgl3B9VW6d9tW
+4uJMv4iC7OXjca17Z4b+3ZFZ1gFEbWyj+yy6wlTVI+Ba7Fh22wNB2We834vLU8Hl
+RrIo8Ufm5x4WO0sr321deu/6eROh7UTN4Os/nR99Lhwpi90B/KYHmdTPzLznnf3T
+SFLssKOIRgQYEQIABgUCQEpkcAAKCRDDLP5SAreFgI1MAJ4iY3P7iRJtJCNXflQ6
+hA7WS6DMMQCgiVuVya7ICdHSs4ln7XkTKtHv2+CZAaIEQ41FlhEEALtHHGJI3KKI
+0FCyqv2BKhfajDaVaQM3u3m9TqIr3DIi5WkBAo9bxIGHlGDGxMQl4IeU/DIrRKu/
+0mHC82cEMKJbCkxn1kRLP+W7WEgXr4+NKIMAyCbKhVLuvcqBZpYVuQSbxi7KkMH1
+Liw84f7vz5kxKQ5s8+lOb8/Hux/qnlLfAKCYuglVEvqv78fY/KmE0DHB+bnzhwQA
+sFDehH6MUOJCcHABQjwINaRKn+xKvUBCvRsE77gnWCLP6yK/sSa+FaZ4UySPeJzP
+ytl37cRpWMIt1Op5marIEGl5J03OA2XdhsfMG3G0K9WuvCP0GF44U5OPyLWxCLH/
+O1I67Ty6LpqWIBJPYpm6dJqMPU2H8ZGtce/7qT2sxmoD/2o6ayh2JQCJeXPwEUiF
+9LyXleFrOec+2CDW4AXLIm+V5xkagBozrU8UvE1OOP5oBPahF+/GONrJONcFHRnE
+5+HzUgMGh2+8brvXBLUoIiFGz8kmO/v3iQ2fa19XwQtvyRs79qZFmHzY5+BrLqx6
+KfkudAuzXH1yOlAqOFXboklgtClDcmFpZyBSLiBNY0NsYW5haGFuIDxjcmFpZ21j
+Y0BhcGFjaGUub3JnPohYBBMRAgAZBQJDjUWWBAsHAwIDFQIDAxYCAQIeAQIXgAAK
+CRD7C1R+62Kp1RkdAJ9SAaNvocDPTz0Y/vdnGZSYWk2khgCYr9gI03EhTzDc/xot
+Qm3XY8+51LkBDQRDjUWZEAQAoT5f9KEix68c4DKX0UZyCQZfgQsCCCJtnYDJK+Ka
+XOarL87JhQksJJ++wFrIAMRKlfavlnNVVOn7KsSk/MG/lrfbJydQU33PyVjAsNoz
+SWQeu3qd7VLbHTloHaIv30v9fVWlcBGzelEsv5Xey394L4a3jENzLRWoqKsJoPBG
+ZasAAwYEAJmt0gl2KmiTmWxWHzhFmDFVIcr05h67noGWw4BT5Zl3vNP4dFhzUOLb
+Lzc5QuQxvpO+7dGuLTfz0MWlpqCk6eukY058zCnuKsm/8d21k0Bx87Pf33qVn7kp
+0WWF9zieDNGvn3c/Nf+C/Yy2yLsN5ynZexfCK14uPNdFla4haPbtiEYEGBECAAYF
+AkONRZkACgkQ+wtUfutiqdWLWgCgiQmd1JMT2hjSoxlQm0hsquNeM+sAnRl85wTJ
+n8b35Wa8gVN1q4eRQEbE
+=YNCS
+-END PGP PUBLIC KEY BLOCK-



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

[Struts Wiki] Update of "ShaleCoreLibrary" by WendySmoak

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 WendySmoak:
http://wiki.apache.org/struts/ShaleCoreLibrary

The comment on the change is:
Added an example of s:token, I don't see it mentioned in xdocs.

New page:
== Shale Core Library JSF Components and Tags ==

 * [http://struts.apache.org/struts-shale/shale-core/tagreference-taglib.html 
Tag Reference]

=== Token ===

{{{
  
 
 
 ...
  
}}}

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

[Struts Wiki] Update of "ShaleTestFramework" by WendySmoak

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 WendySmoak:
http://wiki.apache.org/struts/ShaleTestFramework

New page:

== Tips ==

 * Remember to call super.setUp() and super.tearDown() in your setUp/tearDown 
methods when you extend a class from AbstractJsfTestCase

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

[Struts Wiki] Update of "StrutsShale" by WendySmoak

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 WendySmoak:
http://wiki.apache.org/struts/StrutsShale

--
  
   * 
[http://blogs.sun.com/roller/page/wilfred?entry=building_shale_javaone_demo 
Building JavaOne Shale Demo]
  
- Shale Test framework (this should probably go in a sub-page but I don't know 
how to do that):
+  * ShaleTestFramework
  
- you need to call super.setUp() and super.tearDown() in your setUp/tearDown 
methods when you extend a class from AbstractJsfTestCase
+  * ShaleCoreLibrary
  

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

Re: Clarifications on JSF Vs Struts-Shale

On 11/29/05, Kade Jeevan Kumar <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
>   while i was going through Struts Shale framework.
>
>   I came up with few questions.
>
>   We can go for directly to JSF instead of Struts-JSF using Struts-Shale
> framework it seems this approach is round around.
>
>   By the way JSF is also a kind of framwork similar to Struts 1.x.
>Why need two frameworks?  We can achieve same with JSF.
>
>   I think it will be costly process maintaining two frameworks.

Costly for who?

If you are going to use JSF anyway, and if you're starting on a new project,
and if you have sufficient time to build up your expertise (if it is
lacking) ... by all means start with Shale.  If, on the other hand you have
*existing* Struts based applications and you want to leverage JSF
capabilities, use the integration library.  That can also apply to teams
that have existing Struts expertise and a short deadline (without enough
time to learn a new technology).

It is perfectly reasonable to provide different frameworks for different
requirements -- not everyone has the same needs, or the same schedule
pressures, or the same existing expertise.  Fortunately, open source
projects are not subject to the same economic constraints that closed source
projects are -- given sufficient developers willing to work on both (which
Struts is blessed with), there's no "costly process" to the Struts community
supporting both approaches.

For your own projects, pick the technologies that work best for you.  "Best"
is always relative to the particular situation, though ... in those cases,
isn't it nice to have multiple alternatives from a source you can trust?

  plz, clarify my question.
>
>
>   -Thanks
>   Jeevan

Craig

DO NOT REPLY [Bug 20535] - Dynamically size arrays to allow array types in request scope DynaActionForm forms

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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





--- Additional Comments From [EMAIL PROTECTED]  2005-11-30 06:05 ---
Hi guys, 
I wanted to see if anyone was working on this because I had come up with my own
extension and wanted to know if it would be useful. I'm not up with contributing
stuff to projects like this so I coded a DynaActionForm2 of my own which extends
DynaActionForm. So far I've only used in it in testing, but the principle seems
ok. If you guys want the code, go for it. Here's the text:

package com.lp.struts.ext.action;

import org.apache.struts.action.DynaActionForm;

import java.lang.reflect.Array;
import java.util.List;

/**
 * This class extends
 * [EMAIL PROTECTED] org.apache.struts.action.DynaActionForm DynaActionForm} so 
that we can
 * fix the issues where array references in the properties are not created and
 * cause index exceptions to be thrown. The intent is to re-code the set method
 * so that when an index value is being set, the arrays are extended as
 * necessary by an automatic process. This should remove the necessity for using
 * one of a number of messy work-arounds being used by the struts community.
 * 
 * NOTE after submitting this for comment on java ranch I found out
 * about a similar thing using the Bean utils lazy forms. However when I tried
 * to implement it, I ran into all sorts of problems with implementing. Most
 * notibly they are heavily linked to the use of the Validator which means you
 * must register all forms with it before you can use the lazy forms. It took me
 * some time to work this out because the error messages that are generated are
 * very vague about what the issue is which makes it difficult to sort out.
 * 
 * I also looked at using the commons collection LazyList to drive it. but the
 * issue with that is that it requires the class to provide a factory for
 * generating objects to be stored. This is ok when you know what you are
 * storing but the idea behind a dynaactionform is that you do not.
 * 
 * To cut a long story short this code is smaller, requires no implementation,
 * xml files supporting it or other libraries.
 * 
 * @author Derek Clarkson
 */
public class DynaActionForm2 extends DynaActionForm {

   // @Override
   public void set(String name, int index, Object value) {

  // get the array container from the hashmap of properties. This should
  // return an array object or a list.
  Object prop = this.dynaValues.get(name);

  // error trap.
  if (prop == null) {
 throw new NullPointerException("No such variable: '" + name + "'");
  }

  Class arrayClass = prop.getClass();
  if (arrayClass.isArray()) {

 // First check that the array is big enough. If not then we need to
 // expand it and store the expanded one.
 if (Array.getLength(prop) < index + 1) {
Object newArray = Array.newInstance(arrayClass.getComponentType(),
index + 1);
System.arraycopy(prop, 0, newArray, 0, Array.getLength(prop));
this.dynaValues.put(name, newArray);
prop = newArray;
 }

 // Now store the value.
 Array.set(prop, index, value);

  } else if (prop instanceof List) {

 // Quick local ref for ease of coding.
 List list = (List) prop;

 // Now check the length and expand as necessary.
 if (list.size() < index + 1) {

// I could not see any way of doing this other than this. Basically
// because my criteria was
// that I did not want to replace the list, only expand it because
// then I would not have to deal
// with issues of getting the correct type, etc. Alternatives
// welcome.
for (int i = list.size(); i <= index; i++) {
   list.add(null);
}
 }

 // Store the new value.
 list.set(index, value);

  } else {
 throw new IllegalArgumentException(name + " is not an indexed field.");
  }

   }

}

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Clarifications on JSF Vs Struts-Shale

2005-11-29 Thread Kade Jeevan Kumar

 Hi!
  
  while i was going through Struts Shale framework.
  
  I came up with few questions.
  
  We can go for directly to JSF instead of Struts-JSF using Struts-Shale 
framework it seems this approach is round around.
  
  By the way JSF is also a kind of framwork similar to Struts 1.x. 
   Why need two frameworks?  We can achieve same with JSF.
  
  I think it will be costly process maintaining two frameworks.
  
  
  plz, clarify my question.
  
  
  -Thanks
  Jeevan


-
 Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

Re: Clarification on Shale Framewok

2005-11-29 Thread Martin Cooper

I'd suggest you start by reading the documentation - there's quite a bit of
it - and come back (to the User list, not the Dev list) if you still have
questions after that. See:

http://struts.apache.org/struts-shale/index.html

--
Martin Cooper


On 11/29/05, Kade Jeevan Kumar <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
>   I worked on Struts 1.1 and also on 1.2.  I came across Shale framework
> which is look like the JSF.
>
>   Correct me if am wrong and also kindly help me out to know more abt
> Shale framework.
>
>   I have few questions .
>
>   1) How it is related to Struts framework
>   2) How it works
>   3) Is part of Struts or differ
>   4) How it will be useful/ advantage to existing Struts framework
>   5) What kind of programming language requried for Shale framework
>   6) What i can do with Shale framework.
>   7) Is Shale framework going to compete with other frameworks like JSF,
> which is component oriented architecture
>
>
>   may be my question are repeated but help me out in clearing this
> confusion
>
>   -Thanks
>   Jeevan
>
>
> -
> Yahoo! Music Unlimited - Access over 1 million songs. Try it free.
>

Re: Clarification on Shale Framewok

On 11/29/05, Kade Jeevan Kumar <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
>   I worked on Struts 1.1 and also on 1.2.  I came across Shale framework
> which is look like the JSF.
>
>   Correct me if am wrong and also kindly help me out to know more abt
> Shale framework.

Your best bet for more information is the Shale web site:

http://struts.apache.org/struts-shale/

Brief answers to your questions follow.

  I have few questions .
>
>   1) How it is related to Struts framework

Shale shares the Struts *community*, but it does not share any code with
Struts 1.x.

  2) How it works

Shale assumes that JavaServer Faces already exists, and adds value by
improving functionality and ease of use.

  3) Is part of Struts or differ

Part of the community, but a different software package.

  4) How it will be useful/ advantage to existing Struts framework

If you want to use JSF with an existing Struts app, your best bet would be
to start from the Struts-Faces integration library instead:

http://struts.apache.org/struts-faces/

Using Shale would be an option for new development where you wanted to
leverage JSF.

  5) What kind of programming language requried for Shale framework

Java, of course :-)

  6) What i can do with Shale framework.

Build web applications using Java and JSF technology.

  7) Is Shale framework going to compete with other frameworks like JSF,
> which is component oriented architecture

Shale *requires* JSF and extends it with additional ease of use
capabilities, plus features that users of Struts 1.x are familiar with, such
as Tiles and Commons Validator integration.

  may be my question are repeated but help me out in clearing this confusion
>
>   -Thanks
>   Jeevan

Craig

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

2005-11-29 Thread Laurie Harper


Niall Pemberton wrote:

On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:

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

Niall Pemberton wrote:

Also looked like the property types were the wrong way round for
indexed methods, so I also switched them.

Hmm, with that change, accessing a List property is broken. Without the
change, all my tests are working. You can deploy the exercises app with
the addition I just committed and see for yourself:
  http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do

I've rolled back your change and everything works fine again, including
indexed property access for arrays and lists. The unit test you added
passes either way.

I just refreshed and the JUnit test I wrote is now failing for me.


Its failing in gump as well
http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html

I've had problems with the maven build - when I've used build-all if a
sub-project test fails maven just carries on ignoring it and it
appears you get a successful build. Now I do the sub-projects
separately.

I'm wondering if thats what you used?


I was using 'maven test' without problem. It seems my checkout was 
warped, though, because even though svn was telling me it was 
up-to-date, after an 'svn update' I'm now seeing the failure.


I'll look at it tomorrow and figure out what's wrong.

L.


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

Clarification on Shale Framewok

2005-11-29 Thread Kade Jeevan Kumar

 Hi!
  
  I worked on Struts 1.1 and also on 1.2.  I came across Shale framework which 
is look like the JSF.
  
  Correct me if am wrong and also kindly help me out to know more abt Shale 
framework.   
  
  I have few questions .
  
  1) How it is related to Struts framework
  2) How it works
  3) Is part of Struts or differ
  4) How it will be useful/ advantage to existing Struts framework
  5) What kind of programming language requried for Shale framework
  6) What i can do with Shale framework.
  7) Is Shale framework going to compete with other frameworks like JSF, which 
is component oriented architecture
  
  
  may be my question are repeated but help me out in clearing this confusion
  
  -Thanks
  Jeevan


-
 Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

Re: [shale][clay] Serializability (was Re: [shale] Import statements)

2005-11-29 Thread Mike Kienenberger

On 11/29/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> * CommonsValidator
>
> This is a JSF Validator, so it could well be attached to a UIComponent
> stored in session scope.  It's not obvious from a static review of the code
> what's the problem, but if there is one it'll need to be fixed.

It should either implement StateHolder or Serializable.   In JSF 1.2
and in facelets (1.1 or 1.2), validators are added to the component
tree rather than recreated each request.

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

svn commit: r349871 - /struts/shale/trunk/docs/release-notes-1.0.0.html

2005-11-29 Thread craigmcc

Author: craigmcc
Date: Tue Nov 29 19:40:19 2005
New Revision: 349871

URL: http://svn.apache.org/viewcvs?rev=349871&view=rev
Log:
Take note of an outstanding serializability issue (37707), plus clean up
some cosmetic details.

Modified:
struts/shale/trunk/docs/release-notes-1.0.0.html

Modified: struts/shale/trunk/docs/release-notes-1.0.0.html
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/docs/release-notes-1.0.0.html?rev=349871&r1=349870&r2=349871&view=diff
==
--- struts/shale/trunk/docs/release-notes-1.0.0.html (original)
+++ struts/shale/trunk/docs/release-notes-1.0.0.html Tue Nov 29 19:40:19 2005
@@ -106,11 +106,11 @@
 due to using frames or multiple windoes), and dealing with back buttons.
 These issues will be addressed in a subsequent release.
 
-http://issues.apache.org/bugzilla/show_bug.cgi?id=35839";>35839]
+[http://issues.apache.org/bugzilla/show_bug.cgi?id=35839";>35839]
 Additional improvements to the HTML parser will be addressed in a
 subsequent release.
 
-http://issues.apache.org/bugzilla/show_bug.cgi?id=37024";>37024]
+[http://issues.apache.org/bugzilla/show_bug.cgi?id=37024";>37024]
 The Shale contribution to addressing this issue is to ensure that
 META-INF/clay-config.xml resources from JAR files loaded as
 part of the application are automatically loaded.  This will be addressed
@@ -118,25 +118,34 @@
 component library such as Tomahawk, however, should be provided by the
 component library itself rather than by Shale.
 
-http://issues.apache.org/bugzilla/show_bug.cgi?id=37120";>37120]
+[http://issues.apache.org/bugzilla/show_bug.cgi?id=37120";>37120]
 IFrames are a specific use case related to multiple simultaneous dialogs,
 so this issue will be addressed at the same time as 35066.
 
-http://issues.apache.org/bugzilla/show_bug.cgi?id=37361";>37361]
+[http://issues.apache.org/bugzilla/show_bug.cgi?id=37361";>37361]
 There is a bug in the MyFaces implementation of validation that causes the
 Use Cases example app to fail, where it works with the RI.  The 
corresponding
 MyFaces issue is http://issues.apache.org/jira/browse/MYFACES-829";>
-here.  Leaving this bug open (with state REMIND as a
+here.  Leaving this bug open (with state REMIND) as a
 reminder to flag this issue in Shale release notes until it is resolved
 in a subsequent MyFaces release.
 
-http://issues.apache.org/bugzilla/show_bug.cgi?id=37615";>37615]
+[http://issues.apache.org/bugzilla/show_bug.cgi?id=37615";>37615]
 RFE for using XML namespaces in Clay attributes, to be considered in a
 subsequent release.
 
-http://issues.apache.org/bugzilla/show_bug.cgi?id=37643";>37643]
+[http://issues.apache.org/bugzilla/show_bug.cgi?id=37643";>37643]
 RFE to add documentation (on the web site) for the Tiles and Remoting
 features, to be addressed in a subsequent release.
+
+[http://issues.apache.org/bugzilla/show_bug.cgi?id=37707";>37707]
+Several classes that need to be serializable (because they could be stored
+in session scope) are not currently.  In addition, two classes inherit an
+implements Serializable declaration from their superclass, but
+are not themselves able to be serialized.  This does not cause a problem
+using the classes in Shale, because such instances are never stored into
+session scope, but will be flagged by code audits that check for this
+scenario.
 
   
 



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

DO NOT REPLY [Bug 37707] - [shale] Implement serializability on classes potentially stored in session scope

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||LATER




--- Additional Comments From [EMAIL PROTECTED]  2005-11-30 04:09 ---
To be addressed after initial milestone release is completed.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37707] New: - [shale] Implement serializability on classes potentially stored in session scope

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: [shale] Implement serializability on classes potentially
stored in session scope
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


The following Shale implementation classes can potentially be stored in session
scope (and therefore be required by the J2EE spec to be serializable), but are
not currently serializable:
* org.apache.shale.validator.CommonsValidator
* org.apache.shale.dialog.impl.DialogImpl

Unit tests also need to be added to verify the serializability of these and
other classes that must implement it.

The following classes inherit "implements Serializable" from their parent class
in Commons Chain, even though they are not and cannot actually implement this. 
That is not a direct problem for Shale usage (these classes are only used to
represent per-request state information), but might still get flagged on audits
of a Shale based webapp:
* org.apache.shale.faces.ShaleWebContext
* org.apache.shale.remote.RemoteContext

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [shale][clay] Serializability (was Re: [shale] Import statements)

On 11/29/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
>
> On 11/15/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > On 11/14/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> 
> > >
> > > The other major item its complaining about is non-transient
> > > non-serializable fields in Serializable classes. That explains some of
> > > the NotSerializableException's I get with sticky sessions on Tomcat
> > > startup (mostly in subclasses of Commons Chain's base impls). Will
> > > take a stab at that soon.
> >
> >
> > Thanks ... those are important. Not just because we need to honor the
> > contracts about Serializable session scope attributes, but they also
> > indicate potential architectural issues if we are maintaining references
> to
> > non-Serializable stuff in session scope that should really not be
> > referenced. Struts 1.x has suffered from some of this kind of thing,
> causing
> > memory bloat due to duplicated object trees when you migrate a session
> from
> > one instance to another.
> >
> 
>
> I got around to looking at some code today in serializability's light,
> and that leads to a few questions. I bring this up because I've err'ed
> here before and I wouldn't want [shale] (or [resources] - a similar
> discussion is probably in order on commons-dev) to do the same.

In general, here's the policy that I propose to follow w.r.t. serialization:

* Any class for which an instance might get stored (by the framework,
  or by the application with the blessing of framework documentation
  that says to do so) must be serializable.

* Any class that is not serializable should not claim that it
  "implements Serializable".

That being said, let's review the cases:

First, the offenders include:
>
> [shale]
> * ServletRemoteContext

Only used in the context of a single request.  Unfortunately, there is no
way to say "I'm not Serializabl even though my parent class claims that I
am" ... as is the case here, inherited from Commons chain.

* CommonsValidatorTag

Tag instances are used only in the context of a particular request -- no
reason to worry about serializability.

* CommonsValidator

This is a JSF Validator, so it could well be attached to a UIComponent
stored in session scope.  It's not obvious from a static review of the code
what's the problem, but if there is one it'll need to be fixed.

> * ShalePhaseListener

Never stored in session scope, so doesn't need to be serializable.

* ShaleWebContext

Only used in the context of a single request.  Same "inherited claim" issue
as ServletRemoteContext above.

* StatusImpl

Absolutely has to be serializable -- it's probably the non-static
non-transient Log instance here.

[clay]
> * ClayContext
> * ComponentBean
> * BuilderRuleContext
> * SymbolTag

I don't *think* any of these would ever need to be stored in session scope,
but Gary will need to confirm that.

Some might be serializable, others are clearly not, even with any lazy
> initialization attempts. So, for each, maybe its best to revisit what
> prompted the serializability requirement, and how much each needs to
> be pushed.
>
> My cursory observations:
> * For the *Tag impls there isn't much leeway, so it might be worth
> biting the bullet
> * StatusImpl needs to be serializable by design
> * ShaleWebContext is in a tough spot already (see below)
>
> What are the Shale developers' views on the rest?

See above.

It might not be a bad idea to have test cases to show that the round
> trips work as advertised (I can volunteer some), once this gets sorted
> out.

+1.

In similar scenarios for "day job" projects, we test serializability by
JUnit test cases that try to  serialize and then deserialize instances that
have been configured with various combinations of properties.  Not
foolproof, but certainly catches the obvious cases.

> For the cases where this is really issues with Commons Chain
> implementation
> > classes, we will (of course) need to supply patches for that.
> Fortunately,
> > I'm a committer there too :-).
> >
> 
>
> Yes, having looked at the developer list for [chain], let me ask one
> [OT] question here, and I'll move to commons-dev (or user) if it
> becomes apparent this deserves its own thread:
>
> Digging into [chain], I found a related commit message on top of
> ContextBase [1]. Were there any further developments on that? Seems
> like it may be required to allow subclass implementors (of the base
> impls in chain) to make their own decisions about serializability to
> liberate the *WebContext classes, but that probably won't fit a minor
> release (I'm not even sure if one is planned for [chain]).

It's not obvious what we should do here ... but it's also not a decision we
(Shale developers) or even we (Struts developers) can make in a vacuum.
Needs to be addressed on commons-dev so any other stakeholders who care can
pitch in an opinion.

My other general comment is that right at the moment I want to file an issue
against the Shale classes above that we know need to

[shale][clay] Serializability (was Re: [shale] Import statements)

On 11/15/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 11/14/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote:

> >
> > The other major item its complaining about is non-transient
> > non-serializable fields in Serializable classes. That explains some of
> > the NotSerializableException's I get with sticky sessions on Tomcat
> > startup (mostly in subclasses of Commons Chain's base impls). Will
> > take a stab at that soon.
>
>
> Thanks ... those are important. Not just because we need to honor the
> contracts about Serializable session scope attributes, but they also
> indicate potential architectural issues if we are maintaining references to
> non-Serializable stuff in session scope that should really not be
> referenced. Struts 1.x has suffered from some of this kind of thing, causing
> memory bloat due to duplicated object trees when you migrate a session from
> one instance to another.
>

I got around to looking at some code today in serializability's light,
and that leads to a few questions. I bring this up because I've err'ed
here before and I wouldn't want [shale] (or [resources] - a similar
discussion is probably in order on commons-dev) to do the same.

First, the offenders include:

[shale]
 * ServletRemoteContext
 * CommonsValidatorTag
 * CommonsValidator
 * ShalePhaseListener
 * ShaleWebContext
 * StatusImpl

[clay]
 * ClayContext
 * ComponentBean
 * BuilderRuleContext
 * SymbolTag

Some might be serializable, others are clearly not, even with any lazy
initialization attempts. So, for each, maybe its best to revisit what
prompted the serializability requirement, and how much each needs to
be pushed.

My cursory observations:
 * For the *Tag impls there isn't much leeway, so it might be worth
biting the bullet
 * StatusImpl needs to be serializable by design
 * ShaleWebContext is in a tough spot already (see below)

What are the Shale developers' views on the rest?

It might not be a bad idea to have test cases to show that the round
trips work as advertised (I can volunteer some), once this gets sorted
out.

> For the cases where this is really issues with Commons Chain implementation
> classes, we will (of course) need to supply patches for that. Fortunately,
> I'm a committer there too :-).
>

Yes, having looked at the developer list for [chain], let me ask one
[OT] question here, and I'll move to commons-dev (or user) if it
becomes apparent this deserves its own thread:

Digging into [chain], I found a related commit message on top of
ContextBase [1]. Were there any further developments on that? Seems
like it may be required to allow subclass implementors (of the base
impls in chain) to make their own decisions about serializability to
liberate the *WebContext classes, but that probably won't fit a minor
release (I'm not even sure if one is planned for [chain]).

-Rahul

[1] 
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/impl/ContextBase.java

>
> -Rahul
>
>
> Craig
>

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

Re: Tough Questions on Struts and Webwork Integration

Ted, I've started to bring some of the merger stuff over to the Struts Ti wiki. 
 Could I migrate the FAQ as well, or were you wanting to keep it where it is?


Don

Ted Husted wrote:

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:



Of course, as I send this, I see Patrick responded saying the same thing but
much better :)



See also

* 
http://opensource2.atlassian.com/confluence/oss/display/STRUTS2/WebWork+Merger+FAQ

-Ted.

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




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

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Patrick Lightbody

Actually, Contegix does fully-managed hosting and we might even wish
to use some of the services (wiki, jira, etc) for Struts Ti
development. Contegix is _excellent_ and do everything from handling
upgrades, to 24 hour monitoring and support. Atlassian has donated
JIRA and Confluence licenses, however. Jive (my employer) has also
donated a Forums license.

Patrick

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
> Niall Pemberton wrote:
> > I'm probably going to say something stupid and show my ignorance of
> > WebWork now, but number one on my list would be CoR and integrating
> > Commons Chain commands - both as a replacement for the Struts Action
> > and as a way of inserting custom "request processing" behaviour. I
> > understand WW/XWork has similar Actions / Interceptors, but one of the
> > things I like about Commons Chain is the fact that I can go develop
> > something completely independantly of the framework with just a
> > dependency on a small simple library. I also think that this would
> > provide a confidence that (once Struts 1.3 is out) people could
> > develop Commands (rather than Actions) knowing that they are in the
> > core of a Struts 2.0. Even if there is a slight redundancy with XWork
> > Actions / Chain Commands - I don't see this as a particularly bad
> > thing or too much bloat.
>
> Agreed, and in fact, my first task when I started Struts Ti was to fold in
> support for Commons Chain at the framework level.  XWork/WebWork Actions don't
> even require an interface which I find superior, but I accept not everyone has
> the same taste as me :)
>
> > Another thing would be dynamic beans. It doesn't have to actually be a
> > DynaBean - but some form of configuring a bean rather than coding one
> > would be good.
> >
> > The other areas where our users have invested time and effort are in
> > the configuration and the UI (taglib) and probably more importantly in
> > their knowledge of how to develop using Struts. Someone (Martin I
> > think) proposed providing migration tools for things like
> > configuration, rather than supporting (in the core) things like the
> > struts-config.xml. I think this is one approach and a good idea rather
> > than bloating the core with stuff thats there for backwards
> > compatibility only. However if there are things we can do in the
> > *core* that reduces the learning curve of adopting a new framework for
> > Struts users then I don't think they should be ruled out by Struts 2
> > == WebWork 2.2.
>
> Sure, and these things will become apparent as we start working with the code.
> What I said Struts 2 == WebWork 2.2, I was more referring to the initial 
> import
> and perhaps release.  I agree there are things in Struts that we will want to
> migrate.
>
> >
> > At this point in time the attitude seems to be "don't worry WebWork is
> > not changing, except for package names" and that gives me some concern
> > and I'm hoping that WebWork is coming to the party more in the spirit
> > of a merger and be prepared that there may be changes and that Struts
> > 2.0 is may not be exactly WebWork 2.2?
> >
> > Don't get me wrong, I'm broadly in favour of this merger - although
> > thats based solely on WebWorks reputation and not knowledge of their
> > software and maybe once I'm better informed I'll be more in the "yeah
> > lets throw struts away, WebWork is great as it is camp".
> >
> > Another thing I'd like to know is could someone clarify what would
> > come to Struts. Does XWork come with it or is that staying at open
> > symphony. I tried to find a list of dependencies on the WebWork side,
> > but couldn't - what are WebWorks dependencies? Also if XWork is
> > staying at Open Symphony I'd like to know more about that
> > organisation. Their web site is a .com, the license says its based on
> > Apache - but it doesn't really say anything about what type of
> > organisation Open Symphony is?
>
> XWork is staying at Open Symphony.  OpenSymphony has been around for a while,
> and I haven't heard anything bad about them, other than they used to have
> difficulty keeping their wiki up a while back.  I think Atlassian runs their
> infrastructure now for them.
>
> Don
>
> >
> > Niall
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

[Struts Wiki] Trivial Update of "StrutsTi" 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/StrutsTi

--
  
  '''Struts Ti is in the Struts sandbox for continued development and possible 
eventual acceptance as a Struts subproject, and is NOT an official Struts 
sub-project and as such, is not ready for operational use.'''
  
- = Phase 1 =
+ == Phase 1 ==
  Phase 1 will consist of the [http://www.opensymphy.com/webwork WebWork] 2.2 
codebase, Struts Action 1.x compatibility layer, and perhaps Commons Chain 
integration.
  
- == References ==
+  References 
   * [http://www.mail-archive.com/dev%40struts.apache.org/msg13815.html 
Original Proposal] -- The original !WebWork merger proposal on the Struts dev 
mailing list
   * [http://blogs.opensymphony.com/webwork/2005/11/webwork_joining_struts.html 
Patrick's weblog entry] -- Weblog entry by Patrick Lightbody announcing the 
merger
   * [http://www.theserverside.com/news/thread.tss?thread_id=37794 TSS thread] 
-- The Server Side thread on the merger
   * 
[http://opensource2.atlassian.com/confluence/oss/display/STRUTS2/WebWork+Merger+FAQ
 WebWork merger FAQ] -- Questions and answers regarding the merger
   * [http://www.quicktopic.com/33/H/KBfrHFUehSj/p16.1#QTmsg4 Quicktopic 
thread] -- Quick Topic thread discussing the merger
  
- = Phase 2 =
+ == Phase 2 ==
  Phase 2 will address the original goals of Struts Ti to simply development 
through annotations and workflow.
  
- == Project Management ==
+  Project Management 
   * [wiki:Self:StrutsTi/StatusMatrix Status Matrix] -- Where the project is at 
and where it is going
- == Concepts ==
+  Concepts 
  These pages are a reflection of possibly outdated discussions and not 
necessarily the current direction or implementation.
   * [wiki:Self:StrutsTi/ControllerMock Controller mockup] -- A mock of a 
Controller.java class with a description of its design and features
   * [wiki:Self:StrutsTi/ActionMappings Action mappings] -- Flexible way to map 
URL's to actions
@@ -34, +34 @@

   * [wiki:Self:StrutsTi/XWork XWork] -- Details and discussion of the layer 
that's built on XWork
   * [wiki:Self:StrutsTi/BeehivePageFlow Beehive Page Flow] -- Some info on 
features brought in with Beehive Page Flow
  
- == References ==
+  References 
   * [wiki:Self:StrutsTi/June30Notes June 30 brainstorming notes]
   * [wiki:Self:StrutsTi/OriginalProposal Original proposal]
   * 
http://www-128.ibm.com/developerworks/java/library/wa-rubyonrails/index.html - 
Ruby on Rails vs Struts comparison
  
- == Links ==
+  Links 
   * http://www.opensymphony.com/xwork/ - XWork
   * http://beehive.apache.org/ - Apache Beehive
   * http://jakarta.apache.org/commons/chain/ - Commons Chain

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

[Struts Wiki] Trivial Update of "StrutsTi" 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/StrutsTi

--
   * [http://blogs.opensymphony.com/webwork/2005/11/webwork_joining_struts.html 
Patrick's weblog entry] -- Weblog entry by Patrick Lightbody announcing the 
merger
   * [http://www.theserverside.com/news/thread.tss?thread_id=37794 TSS thread] 
-- The Server Side thread on the merger
   * 
[http://opensource2.atlassian.com/confluence/oss/display/STRUTS2/WebWork+Merger+FAQ
 WebWork merger FAQ] -- Questions and answers regarding the merger
+  * [http://www.quicktopic.com/33/H/KBfrHFUehSj/p16.1#QTmsg4 Quicktopic 
thread] -- Quick Topic thread discussing the merger
  
  = Phase 2 =
  Phase 2 will address the original goals of Struts Ti to simply development 
through annotations and workflow.

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

[Struts Wiki] Trivial Update of "StrutsTi" 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/StrutsTi

The comment on the change is:
Cleaned up webwork links

--
  
  The key word for Struts Ti is simplicity.  Ideally, Struts Ti should approach 
Ruby on Rails levels of easy of use, yet scale up to large applications 
providing a smooth transition to JSF if desired.  
  
- The big announcement of Struts Ti is that it includes a merger between Struts 
and WebWork, such that Struts Ti will start with  the migrated WebWork 2.2 
codebase.  This development as pushed back some of the annotation-driven next 
generation features as the first goal is now to create a stable core consisting 
of the WebWork codebase and a new Struts Action 1.x compatibility layer to 
assist in application migration.
+ The big announcement of Struts Ti is that it includes a merger between Struts 
and [http://www.opensymphy.com/webwork WebWork], such that Struts Ti will start 
with  the migrated [http://www.opensymphy.com/webwork WebWork] 2.2 codebase.  
This development as pushed back some of the annotation-driven next generation 
features as the first goal is now to create a stable core consisting of the 
[http://www.opensymphy.com/webwork WebWork] codebase and a new Struts Action 
1.x compatibility layer to assist in application migration.
  
  '''Struts Ti is in the Struts sandbox for continued development and possible 
eventual acceptance as a Struts subproject, and is NOT an official Struts 
sub-project and as such, is not ready for operational use.'''
  
  = Phase 1 =
- Phase 1 will consist of the WebWork 2.2 codebase, Struts Action 1.x 
compatibility layer, and perhaps Commons Chain integration.
+ Phase 1 will consist of the [http://www.opensymphy.com/webwork WebWork] 2.2 
codebase, Struts Action 1.x compatibility layer, and perhaps Commons Chain 
integration.
  
  == References ==
-  * [http://www.mail-archive.com/dev%40struts.apache.org/msg13815.html 
Original Proposal] -- The original WebWork merger proposal on the Struts dev 
mailing list
+  * [http://www.mail-archive.com/dev%40struts.apache.org/msg13815.html 
Original Proposal] -- The original !WebWork merger proposal on the Struts dev 
mailing list
   * [http://blogs.opensymphony.com/webwork/2005/11/webwork_joining_struts.html 
Patrick's weblog entry] -- Weblog entry by Patrick Lightbody announcing the 
merger
   * [http://www.theserverside.com/news/thread.tss?thread_id=37794 TSS thread] 
-- The Server Side thread on the merger
   * 
[http://opensource2.atlassian.com/confluence/oss/display/STRUTS2/WebWork+Merger+FAQ
 WebWork merger FAQ] -- Questions and answers regarding the merger

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

[Struts Wiki] Update of "StrutsTi" 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/StrutsTi

The comment on the change is:
Adding new Struts Ti information

--
  
  The key word for Struts Ti is simplicity.  Ideally, Struts Ti should approach 
Ruby on Rails levels of easy of use, yet scale up to large applications 
providing a smooth transition to JSF if desired.  
  
+ The big announcement of Struts Ti is that it includes a merger between Struts 
and WebWork, such that Struts Ti will start with  the migrated WebWork 2.2 
codebase.  This development as pushed back some of the annotation-driven next 
generation features as the first goal is now to create a stable core consisting 
of the WebWork codebase and a new Struts Action 1.x compatibility layer to 
assist in application migration.
+ 
  '''Struts Ti is in the Struts sandbox for continued development and possible 
eventual acceptance as a Struts subproject, and is NOT an official Struts 
sub-project and as such, is not ready for operational use.'''
+ 
+ = Phase 1 =
+ Phase 1 will consist of the WebWork 2.2 codebase, Struts Action 1.x 
compatibility layer, and perhaps Commons Chain integration.
+ 
+ == References ==
+  * [http://www.mail-archive.com/dev%40struts.apache.org/msg13815.html 
Original Proposal] -- The original WebWork merger proposal on the Struts dev 
mailing list
+  * [http://blogs.opensymphony.com/webwork/2005/11/webwork_joining_struts.html 
Patrick's weblog entry] -- Weblog entry by Patrick Lightbody announcing the 
merger
+  * [http://www.theserverside.com/news/thread.tss?thread_id=37794 TSS thread] 
-- The Server Side thread on the merger
+  * 
[http://opensource2.atlassian.com/confluence/oss/display/STRUTS2/WebWork+Merger+FAQ
 WebWork merger FAQ] -- Questions and answers regarding the merger
+ 
+ = Phase 2 =
+ Phase 2 will address the original goals of Struts Ti to simply development 
through annotations and workflow.
  
  == Project Management ==
   * [wiki:Self:StrutsTi/StatusMatrix Status Matrix] -- Where the project is at 
and where it is going

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

Re: Tough Questions on Struts and Webwork Integration


Niall Pemberton wrote:

I'm probably going to say something stupid and show my ignorance of
WebWork now, but number one on my list would be CoR and integrating
Commons Chain commands - both as a replacement for the Struts Action
and as a way of inserting custom "request processing" behaviour. I
understand WW/XWork has similar Actions / Interceptors, but one of the
things I like about Commons Chain is the fact that I can go develop
something completely independantly of the framework with just a
dependency on a small simple library. I also think that this would
provide a confidence that (once Struts 1.3 is out) people could
develop Commands (rather than Actions) knowing that they are in the
core of a Struts 2.0. Even if there is a slight redundancy with XWork
Actions / Chain Commands - I don't see this as a particularly bad
thing or too much bloat.


Agreed, and in fact, my first task when I started Struts Ti was to fold in 
support for Commons Chain at the framework level.  XWork/WebWork Actions don't 
even require an interface which I find superior, but I accept not everyone has 
the same taste as me :)



Another thing would be dynamic beans. It doesn't have to actually be a
DynaBean - but some form of configuring a bean rather than coding one
would be good.

The other areas where our users have invested time and effort are in
the configuration and the UI (taglib) and probably more importantly in
their knowledge of how to develop using Struts. Someone (Martin I
think) proposed providing migration tools for things like
configuration, rather than supporting (in the core) things like the
struts-config.xml. I think this is one approach and a good idea rather
than bloating the core with stuff thats there for backwards
compatibility only. However if there are things we can do in the
*core* that reduces the learning curve of adopting a new framework for
Struts users then I don't think they should be ruled out by Struts 2
== WebWork 2.2.


Sure, and these things will become apparent as we start working with the code. 
What I said Struts 2 == WebWork 2.2, I was more referring to the initial import 
and perhaps release.  I agree there are things in Struts that we will want to 
migrate.




At this point in time the attitude seems to be "don't worry WebWork is
not changing, except for package names" and that gives me some concern
and I'm hoping that WebWork is coming to the party more in the spirit
of a merger and be prepared that there may be changes and that Struts
2.0 is may not be exactly WebWork 2.2?

Don't get me wrong, I'm broadly in favour of this merger - although
thats based solely on WebWorks reputation and not knowledge of their
software and maybe once I'm better informed I'll be more in the "yeah
lets throw struts away, WebWork is great as it is camp".

Another thing I'd like to know is could someone clarify what would
come to Struts. Does XWork come with it or is that staying at open
symphony. I tried to find a list of dependencies on the WebWork side,
but couldn't - what are WebWorks dependencies? Also if XWork is
staying at Open Symphony I'd like to know more about that
organisation. Their web site is a .com, the license says its based on
Apache - but it doesn't really say anything about what type of
organisation Open Symphony is?


XWork is staying at Open Symphony.  OpenSymphony has been around for a while, 
and I haven't heard anything bad about them, other than they used to have 
difficulty keeping their wiki up a while back.  I think Atlassian runs their 
infrastructure now for them.


Don



Niall

-
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: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Ted Husted

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:

> Of course, as I send this, I see Patrick responded saying the same thing but
> much better :)

See also

* 
http://opensource2.atlassian.com/confluence/oss/display/STRUTS2/WebWork+Merger+FAQ

-Ted.

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

Re: Tough Questions on Struts and Webwork Integration

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
> Niall Pemberton wrote:
> > Its probably a great plan to switch to WebWork 2.2 but I still don't
> > see how you can say its a "merger" if no Struts code is involved -
> > merger in terms of community, but not software.
>
> I view this merger as first, one of projects/community, and second, one of 
> code.

For WebWork I agree, but from a Struts perspective its the other way
round, although if WebWork code is as good as its reputation then the
WebWork developers (Patrick, Jason, anyone else?) will be very welcome
additions to our community.

>  Just because the Struts Action 1.x compatibility layer will be separate from
> the Struts Ti core (WebWork 2.2), doesn't mean we haven't merged code.  In 
> fact,
> I'd consider that a prime example of the merger, because the Struts Action 
> code
> will need to be "merged" into the Struts Ti core framework while retaining 
> much
> of its original functionality.

OK, but when I hear "optional compatibility" to me it sounds like a
"deprecated" warning (i.e. you can use it for now but you really need
to move on before this disappears) and I had thought that there would
be some things that merged from Struts into the *core* of a Struts
2.0.

I'm probably going to say something stupid and show my ignorance of
WebWork now, but number one on my list would be CoR and integrating
Commons Chain commands - both as a replacement for the Struts Action
and as a way of inserting custom "request processing" behaviour. I
understand WW/XWork has similar Actions / Interceptors, but one of the
things I like about Commons Chain is the fact that I can go develop
something completely independantly of the framework with just a
dependency on a small simple library. I also think that this would
provide a confidence that (once Struts 1.3 is out) people could
develop Commands (rather than Actions) knowing that they are in the
core of a Struts 2.0. Even if there is a slight redundancy with XWork
Actions / Chain Commands - I don't see this as a particularly bad
thing or too much bloat.

Another thing would be dynamic beans. It doesn't have to actually be a
DynaBean - but some form of configuring a bean rather than coding one
would be good.

The other areas where our users have invested time and effort are in
the configuration and the UI (taglib) and probably more importantly in
their knowledge of how to develop using Struts. Someone (Martin I
think) proposed providing migration tools for things like
configuration, rather than supporting (in the core) things like the
struts-config.xml. I think this is one approach and a good idea rather
than bloating the core with stuff thats there for backwards
compatibility only. However if there are things we can do in the
*core* that reduces the learning curve of adopting a new framework for
Struts users then I don't think they should be ruled out by Struts 2
== WebWork 2.2.

At this point in time the attitude seems to be "don't worry WebWork is
not changing, except for package names" and that gives me some concern
and I'm hoping that WebWork is coming to the party more in the spirit
of a merger and be prepared that there may be changes and that Struts
2.0 is may not be exactly WebWork 2.2?

Don't get me wrong, I'm broadly in favour of this merger - although
thats based solely on WebWorks reputation and not knowledge of their
software and maybe once I'm better informed I'll be more in the "yeah
lets throw struts away, WebWork is great as it is camp".

Another thing I'd like to know is could someone clarify what would
come to Struts. Does XWork come with it or is that staying at open
symphony. I tried to find a list of dependencies on the WebWork side,
but couldn't - what are WebWorks dependencies? Also if XWork is
staying at Open Symphony I'd like to know more about that
organisation. Their web site is a .com, the license says its based on
Apache - but it doesn't really say anything about what type of
organisation Open Symphony is?

Niall

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

Merger - A suggestion for a next step

2005-11-29 Thread Ted Husted

Rather than cross post to both dev lists, I posted to the QuickTopic thread

* http://www.quicktopic.com/33/H/KBfrHFUehSj

-Ted.

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

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Martin Cooper

On 11/29/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
> On 11/29/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> >
> > > > Let's reserve Tuesday night, after the two Struts related sessions,
> to
> > have
> > > > these conversations.
> >
> > Sounds good.  Perhaps we should discuss over beer?
>
>
> Beer is good :-).   Indeed, the only bummer about ApacheCon this year is
> that the timing overlaps with JavaPolis in Antwerp ... I have many happy
> memories of enjoying Belgian beers while supervising development projects
> over there a few years back.
>
> But we'll need a couple of envelopes with blank backs too.


Beer mats, perhaps? ;-)

--
Martin Cooper


> Don
> >
> > sean
>
>
> Craig
>
>
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>

Re: Tough Questions on Struts and Webwork Integration

On 11/29/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> > > Let's reserve Tuesday night, after the two Struts related sessions, to
> have
> > > these conversations.
>
> Sounds good.  Perhaps we should discuss over beer?

Beer is good :-).   Indeed, the only bummer about ApacheCon this year is
that the timing overlaps with JavaPolis in Antwerp ... I have many happy
memories of enjoying Belgian beers while supervising development projects
over there a few years back.

But we'll need a couple of envelopes with blank backs too.

> Don
>
> sean

Craig

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

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Peter A. Pilgrim


Don Brown wrote:

Craig McClanahan wrote:


On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:


Actually, I'd love for Shale and Struts Ti to collaborate more, and in a
perfect world, both depend on the same core.  Struts Ti won't be
JSF-specific (ever), but that doesn't mean it can't integrate with JSF.
 I'm looking forward to ApacheCon so we can sit down with Craig and
look at ways we can work together better.  Put simply, I fully expect
Struts Ti to support JSF, and hopefully Shale, in the future in some 
form.





Let's reserve Tuesday night, after the two Struts related sessions, to 
have

these conversations.



Perfect, I look forward to it.

Don



Don


Craig




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



After your conservations, can you keep us all posted with a synopsis?

TIA

--
Peter Pilgrim
   __ _ _ _
  / //__  // ___// ___/   +  Serverside Java
 / /___/ // /__ / /__ +  Struts
/ // ___// ___// ___/ +  Expresso Committer
 __/ // /__ / /__ / /__   +  Independent Contractor
/___///////   +  Intrinsic Motivation
On Line Resume
   ||
   \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''

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

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Sean Schofield

> > Let's reserve Tuesday night, after the two Struts related sessions, to have
> > these conversations.

Sounds good.  Perhaps we should discuss over beer?

> Don

sean

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

Re: Tough Questions on Struts and Webwork Integration


Craig McClanahan wrote:

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:


Actually, I'd love for Shale and Struts Ti to collaborate more, and in a
perfect world, both depend on the same core.  Struts Ti won't be
JSF-specific (ever), but that doesn't mean it can't integrate with JSF.
 I'm looking forward to ApacheCon so we can sit down with Craig and
look at ways we can work together better.  Put simply, I fully expect
Struts Ti to support JSF, and hopefully Shale, in the future in some form.




Let's reserve Tuesday night, after the two Struts related sessions, to have
these conversations.


Perfect, I look forward to it.

Don



Don


Craig




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

Re: Tough Questions on Struts and Webwork Integration

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
>
> Actually, I'd love for Shale and Struts Ti to collaborate more, and in a
> perfect world, both depend on the same core.  Struts Ti won't be
> JSF-specific (ever), but that doesn't mean it can't integrate with JSF.
>   I'm looking forward to ApacheCon so we can sit down with Craig and
> look at ways we can work together better.  Put simply, I fully expect
> Struts Ti to support JSF, and hopefully Shale, in the future in some form.


Let's reserve Tuesday night, after the two Struts related sessions, to have
these conversations.

Don


Craig

[EMAIL PROTECTED]: Project struts-action (in module struts) failed

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-action has an issue affecting its community integration.
This issue affects 85 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-faces :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-portal-sample :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- commons-jelly-tags-ojb :  Commons Jelly
- commons-jelly-tags-quartz :  Commons Jelly
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- fulcrum-quartz :  Services Framework
- fulcrum-security-adapter-turbine :  Services Framework
- jakarta-tomcat-5 :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- jakarta-velocity-tools :  Velocity-Tools project
- lenya :  Content Management System
- myfaces :  JavaServer(tm) Faces implementation
- portals-bridges-frameworks :  Support for JSR168 compliant Portlet 
development
- portals-bridges-jsf :  Support for JSR168 compliant Portlet development
- portals-bridges-struts :  Support for JSR168 compliant Portlet development
- portals-bridges-velocity :  Support for JSR168 compliant Portlet 
development
- portals-jetspeed-1 :  Enterprise Information Portal
- quartz :  Job Scheduler
- smartfrog-tomcat :  Smartfrog: Application Deployment from HP Laboratories
- struts-action :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-el :  Model 2 Model-View-Controller framework for Servlets and JSP
- struts-sslext :  The Struts SSL Extension for HTTP/HTTPS switching
- struts-taglib :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-tiles :  Model 2 Model-View-Contr

[EMAIL PROTECTED]: Project struts-action (in module struts) failed

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-action has an issue affecting its community integration.
This issue affects 85 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-faces :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-portal-sample :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- commons-jelly-tags-ojb :  Commons Jelly
- commons-jelly-tags-quartz :  Commons Jelly
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- fulcrum-quartz :  Services Framework
- fulcrum-security-adapter-turbine :  Services Framework
- jakarta-tomcat-5 :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- jakarta-velocity-tools :  Velocity-Tools project
- lenya :  Content Management System
- myfaces :  JavaServer(tm) Faces implementation
- portals-bridges-frameworks :  Support for JSR168 compliant Portlet 
development
- portals-bridges-jsf :  Support for JSR168 compliant Portlet development
- portals-bridges-struts :  Support for JSR168 compliant Portlet development
- portals-bridges-velocity :  Support for JSR168 compliant Portlet 
development
- portals-jetspeed-1 :  Enterprise Information Portal
- quartz :  Job Scheduler
- smartfrog-tomcat :  Smartfrog: Application Deployment from HP Laboratories
- struts-action :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-el :  Model 2 Model-View-Controller framework for Servlets and JSP
- struts-sslext :  The Struts SSL Extension for HTTP/HTTPS switching
- struts-taglib :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-tiles :  Model 2 Model-View-Contr

Re: Tough Questions on Struts and Webwork Integration


Michael Jouravlev wrote:

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:


Niall Pemberton wrote:


Its probably a great plan to switch to WebWork 2.2 but I still don't
see how you can say its a "merger" if no Struts code is involved -
merger in terms of community, but not software.


I view this merger as first, one of projects/community, and second, one of code.



Don, does Jürgen Schrempp happen to be your brother? ;-)


Ok, that one took a Googling, and I have the distinct impression I should be 
offended :)



...and learn Webwork *then* after all. Why not to simply say "Struts
sucks, let's drop it and march together into the better future under
OpenSymphony standard?" Why the need of keeping *this* community
*here* instead of moving/creating community *there* ?


That's a valid question.  Here is what I think Apache, and in particular, the 
Apache Software Foundation brings:

 - Strong infrastructure
 - Good legal standing/support
 - Well known
 - Strong organizational structure

The Struts project itself brings a rich history, strong brand name, tried and 
true experience, and yes, I believe there is some code in Struts Action 1.x 
worth merging.


Of course, as I send this, I see Patrick responded saying the same thing but 
much better :)


Don



Michael.

-
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: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread netsql


Great. I don't think it requires JSF.
It also works w/ Ajax and has Ajax modules (and that has little to do w/ 
JSF afiak).
Sounds like a simple resolution: Shale can be JSF centric but not 
require it so it works w/ other (rich, client side) views.

We we lived happily ever after.
.V

Don Brown wrote:
The sticking point is Shale requires JSF, and Struts Ti does not want 
that dependency.  My hope is we will be able to find code in both 
projects that could be shared, somehow.


Don




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

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Patrick Lightbody

> ...and learn Webwork *then* after all. Why not to simply say "Struts
> sucks, let's drop it and march together into the better future under
> OpenSymphony standard?" Why the need of keeping *this* community
> *here* instead of moving/creating community *there* ?

First time poster :)

I would say that is a rather childish way to look at it. Struts offers
more than just code. It is a rich community full of tons of users,
books, knowledge, and developers. To look at Struts or WebWork as
simply Java source files would be an inaccurate representation.

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

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Michael Jouravlev

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
> Niall Pemberton wrote:
> > Its probably a great plan to switch to WebWork 2.2 but I still don't
> > see how you can say its a "merger" if no Struts code is involved -
> > merger in terms of community, but not software.
> I view this merger as first, one of projects/community, and second, one of 
> code.

Don, does Jürgen Schrempp happen to be your brother? ;-)

On 11/29/05, Pilgrim, Peter <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: Don Brown [mailto:[EMAIL PROTECTED]
> > Struts Ti == WebWork 2.2, with some package
> > name changes.
>
> Ok it makes a little clearer.
> So developers have a choice?
>
> 1) Learn the WebWork 2.x philosophy
>
> 2) Don't learn WW2 way but use the Struts compatibility layer
> instead until it runs out of steam or is it deprecated.

...and learn Webwork *then* after all. Why not to simply say "Struts
sucks, let's drop it and march together into the better future under
OpenSymphony standard?" Why the need of keeping *this* community
*here* instead of moving/creating community *there* ?

Michael.

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

Re: Tough Questions on Struts and Webwork Integration

The sticking point is Shale requires JSF, and Struts Ti does not want that 
dependency.  My hope is we will be able to find code in both projects that could 
be shared, somehow.


Don

netsql wrote:

The features that are in Ti and WebWork, can they be bolted on Shale?

.V

Don Brown wrote:

Actually, I'd love for Shale and Struts Ti to collaborate more, and in 
a perfect world, both depend on the same core.  Struts Ti won't be 
JSF-specific (ever), but that doesn't mean it can't integrate with 
JSF.  I'm looking forward to ApacheCon so we can sit down with Craig 
and look at ways we can work together better.  Put simply, I fully 
expect Struts Ti to support JSF, and hopefully Shale, in the future in 
some form.


Don

netsql wrote:

idealy ... it be great to bolt on webwork and ti features on top of 
Shale code base, or at worst fork Shale as a starting point.


there I said it!

.V


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




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




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

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread netsql


The features that are in Ti and WebWork, can they be bolted on Shale?

.V

Don Brown wrote:
Actually, I'd love for Shale and Struts Ti to collaborate more, and in a 
perfect world, both depend on the same core.  Struts Ti won't be 
JSF-specific (ever), but that doesn't mean it can't integrate with JSF. 
 I'm looking forward to ApacheCon so we can sit down with Craig and look 
at ways we can work together better.  Put simply, I fully expect Struts 
Ti to support JSF, and hopefully Shale, in the future in some form.


Don

netsql wrote:

idealy ... it be great to bolt on webwork and ti features on top of 
Shale code base, or at worst fork Shale as a starting point.


there I said it!

.V


-
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: Tough Questions on Struts and Webwork Integration

Pilgrim, Peter wrote:

Ok great so is Ted Husted also involved in the 2nd edition
and I presume Manning is fine with both Struts in Action
and Webwork in Action in the future ``merging'' as one.

Ted has helped early on by reviewing our proposal and TOC, but the book is being
written by Nick Heudecker (of Hibernate Quickly) and myself. I actually haven't
talked to Manning since the merger was announced :) but they did know big
changes were in the works.

I have just read Niall's question and answer. So WebWork will
probably usurp the Struts Core layer at some point, correct?

I'm not sure what you mean. The WebWork 2.2 code will become Struts Ti core,
hopefully the basis for Struts Action 2.0. I see both Struts Action 1.x and
Struts Action 2.0 as viable frameworks for developers to work with.

Ok it makes a little clearer.
So developers have a choice?

1) Learn the WebWork 2.x philosophy

2) Don't learn WW2 way but use the Struts compatibility layer
instead until it runs out of steam or is it deprecated.

Sure, although I imagine the compatibility layer is there mostly for application
migration and not so much for new development. I think there is a lot of value
in being able to upgrade your application piece by piece and not requiring a
huge rewrite, which is I believe one of the big selling points of Struts Ti as
opposed to JSF.

That begs the question, what is the best way for Struts developer
to learn WebWork 2.

I'd say pick up the WebWork in Action book
(http://www.manning.com/books/lightbody) written by the primary WebWork
developers themselves. Of course once Struts in Action 2ed comes out, it will
be better ;)

So Struts Ti definitely requires Java 5, because of annotations.

Nope. The first phase of Struts Ti won't have the annotation stuff in there,
but the second phase will probably use a nifty annotation/tag layer Rich Feit of
Beehive wrote which allows developers the choice to use Java 5 annotations or
XDoclet style tags.

Therefore, to be clear, Struts Ti will only require Java 1.4 or greater, just
like Struts Action 1.3.

Thanks for answering my questions

No problem. They were such good questions, in fact, I'll try to make them into
a FAQ on the wiki here soon, as I imagine they will be quite common. :)

Don

References:

http://www.theserverside.com/news/thread.tss?thread_id=37794

http://blogs.opensymphony.com/webwork/

http://www.manning.com/books/lightbody

====

--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston,
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom

Tel: +44-(0)207-883-4497

==
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

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

RE: Tough Questions on Struts and Webwork Integration


> -Original Message-
> From: Don Brown [mailto:[EMAIL PROTECTED]
> Sent: 29 November 2005 16:27
> To: Struts Developers List
> Subject: Re: Tough Questions on Struts and Webwork Integration
> 
> 
> These are some great questions, and particularly relevant to 
> me as I'm 
> working on the 2ed edition of Struts in Action.  You can be sure our 
> book will cover, at least in part, Struts Ti.  Here is my 2c:
> 

Ok great so is Ted Husted also involved in the 2nd edition
and I presume Manning is fine with both Struts in Action 
and Webwork in Action in the future ``merging'' as one.

> Pilgrim, Peter wrote:
> > Hi
> > 
> > 1) Is the WebWork name going to exist still?
> 
> No, at least not in Apache Struts.  The WebWork project will probably 
> stick around supporting 1.x and possibly to host migration code.
> 

I have just read Niall's question and answer. So WebWork will 
probably usurp the Struts Core layer at some point, correct?

> > 2) Is the Struts name going to be annexed with WebWork?
> 
> Nope.  While initially, this WebWork import will be called 
> Struts Ti, it 
> is my hope it will quickly be accepted as Struts Action 2.0.
> 
> > 3) A users has invested his or her hard-earned cash in 
> `WebWork' in Action book.
> > Will contents of this tome still be relevant in Struts?
> 
> Absolutely, since Struts Ti == WebWork 2.2, with some package 
> name changes.
> 

Ok it makes a little clearer.
So developers have a choice?

1) Learn the WebWork 2.x philosophy

2) Don't learn WW2 way but use the Struts compatibility layer
instead until it runs out of steam or is it deprecated.

> > 4) In fact there are a number of such books on the markets 
> e.g Struts Receipes 
> > and Struts Cookbook. Are these book becoming irrevelant or 
> still revelant? 
> > Have the book publishers lost a dosh of cash, then ?
> 
> These books will continue to be important due to:
> 1. All the existing Struts Action 1.x applications out there
> 2. The Struts Action 1.x will continue to be supported and developed
> 
> Just because there might be a Struts Action 2.0, doesn't mean 
> development or support will stop on 1.x.  WebWork itself is a good 
> example of this as their 1.x community is still quite alive.
> 
> > 5) What architectural components are going to be replaced 
> in Struts ?
> > ( And conversely in Webwork?)
> 
> This is a tough question because we haven't started on the Struts 
> compatibility layer so I can't tell you what we can support 
> from Struts. 
>   WebWork will be imported as is, so I don't see anything 
> replaced there 
> initially, however, we might decide to remove some deprecations.
> 

That begs the question, what is the best way for Struts developer
to learn WebWork 2.

> I can tell you it is my personal goal for the Struts 
> compatibility layer 
> to support to some extent Struts Actions, ActionForms, Validator, and 
> Tiles at least.
> 
> > 6) What happens to the custom tag libraries like HTML or HTML-EL?
> 
> These, of course, will still be supported by Struts 1.x.  We 
> might find 
> it possible to simulate them with the Struts compatibility layer, I 
> don't know yet.  Still, I think you'll really like the WebWork tags 
> since they support multiple template technologies (JSP, Velocity, 
> FreeMarker, etc) and have "themes" which include an Ajax 
> theme that uses 
> Dojo.

Cool! I have been listening to alot of interesting stuff about Dojo
from Ajaxian.com

> 
> > 7) Will Struts users suddenly now have to learn OGNL thing?
> 
> Struts 1.x users, of course, won't, and while initially 
> Struts Ti users 
> will, one of our goals in Struts Ti has been to make that 
> pluggable so 
> you could stick JSP EL there or even XPath.
> 
> > 8) How will the Webwork Integration affect popular Struts 
> extensions such as the Validator or Tiles?
> 
> Again, it is my goal the compatibility layer or even Struts Ti itself 
> will support them.  To be honest, I'm not to keen on making Validator 
> support core, because I personally think there are better ways to do 
> validation, but Tiles will be important to support.  There is 
> a version 
> of Tiles that is being worked on which doesn't require Struts 
> at all, so 
> it is possible it could be easily used with Struts Ti.
> 
> > 9) A Girl named Geraldine (or A Guy named Gerald if you are 
> so inclined) has invested in 
> > heavily Spring supported Struts Actions, and has read your 
> recent announcement and 
> > she proclaims "What Do I Do Now?!"
> 
> Keep on keeping on.  I too have a Struts Action 1.x application that 
> uses Spring-supported Actions and plan to be supporting it 
> for a while. 
>   Struts Ti, if she was interested in it for new apps, will contain 
> heavy Spring integration which might be a better choice.
> 
> > ( Spring support AOP already, so does it fit with the 
> WebWork interceptors? )
> 
> Two different things, really, so yes, they compliment each other well.
> 
> > 10) "What does WebWork really bring to the Struts party?

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Nathan Bubna

On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
> > First, we bring in the WebWork 2.2 code which forms the Struts Ti core.
> >  Then, we develop a Struts compatibility layer.  Along the way, if we
> > see anything from Struts Action 1.x that should also go into Struts Ti
> > core, we can add it.  Honestly, I don't really see anything of Struts
> > Action 1.x that isn't done better in WebWork, so yes, I still think it
> > is a merger, but being this is targetted for Struts Action 2.0, I think
> > it is appropriate to be such a large rewrite.  Even if we wrote Struts
> > Action 2.0 from scratch, I doubt we'd see much from Struts Action 1.x
> > we'd want to carry over.
>
> Its probably a great plan to switch to WebWork 2.2 but I still don't
> see how you can say its a "merger" if no Struts code is involved -
> merger in terms of community, but not software.

i would say the merging of communities and effort is far and away the
important part.  that's certainly the interesting part to me.  i can't
imagine any sane way to do a code merger apart from the proposed
compatibility layer.  so the community/effort merging has been my
understanding from the get-go.

> > And as with WebWork 1.x and as we've been saying from the beginning,
> > Struts Action 1.x will continue to be developed and supported, so I
> > wouldn't even call that a deprecation.
>
> If its agreed we move to WebWork 2.2 for Struts 2.0 then why would we
> continue developing Struts 1.x? I wouldn't want to, it would be a
> waste of time - would you anticipate doing any/much Struts 1.x
> development in this scenario?
>
> > But again, that is my 2c which may not reflect the opinions of the
> > Struts PMC as a whole.
> >
> > Don
> >
> > Niall Pemberton wrote:
> > > On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
> > > 
> > >
> > >>>3) A users has invested his or her hard-earned cash in `WebWork' in 
> > >>>Action book.
> > >>>Will contents of this tome still be relevant in Struts?
> > >>
> > >>Absolutely, since Struts Ti == WebWork 2.2, with some package name 
> > >>changes.
> > >>
> > >
> > > 
> > >
> > > 
> > >
> > >>>5) What architectural components are going to be replaced in Struts ?
> > >>>( And conversely in Webwork?)
> > >>
> > >>This is a tough question because we haven't started on the Struts
> > >>compatibility layer so I can't tell you what we can support from Struts.
> > >> WebWork will be imported as is, so I don't see anything replaced there
> > >>initially, however, we might decide to remove some deprecations.
> > >>
> > >>I can tell you it is my personal goal for the Struts compatibility layer
> > >>to support to some extent Struts Actions, ActionForms, Validator, and
> > >>Tiles at least.
> > >
> > > 
> > >
> > > I thought the proposal was to merge Struts and WebWork - from this and
> > > what : Jason Carreira said on TSS the actual proposal is that Struts
> > > Action/Classic is dumped and a migration path for Struts users to
> > > WebWork 2.2 be provided?
> > >
> > > If this is the case then rather than calling this a proposed merger
> > > wouldn't it be clearer to say that the proposal is to "deprecate
> > > Struts in favour of WebWork"?
> > >
> > > Niall
> > >
> > >
> > >>Don
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Tough Questions on Struts and Webwork Integration



Niall Pemberton wrote:

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:


First, we bring in the WebWork 2.2 code which forms the Struts Ti core.
Then, we develop a Struts compatibility layer.  Along the way, if we
see anything from Struts Action 1.x that should also go into Struts Ti
core, we can add it.  Honestly, I don't really see anything of Struts
Action 1.x that isn't done better in WebWork, so yes, I still think it
is a merger, but being this is targetted for Struts Action 2.0, I think
it is appropriate to be such a large rewrite.  Even if we wrote Struts
Action 2.0 from scratch, I doubt we'd see much from Struts Action 1.x
we'd want to carry over.



Its probably a great plan to switch to WebWork 2.2 but I still don't
see how you can say its a "merger" if no Struts code is involved -
merger in terms of community, but not software.


I view this merger as first, one of projects/community, and second, one of code. 
 Just because the Struts Action 1.x compatibility layer will be separate from 
the Struts Ti core (WebWork 2.2), doesn't mean we haven't merged code.  In fact, 
I'd consider that a prime example of the merger, because the Struts Action code 
will need to be "merged" into the Struts Ti core framework while retaining much 
of its original functionality.







And as with WebWork 1.x and as we've been saying from the beginning,
Struts Action 1.x will continue to be developed and supported, so I
wouldn't even call that a deprecation.



If its agreed we move to WebWork 2.2 for Struts 2.0 then why would we
continue developing Struts 1.x? I wouldn't want to, it would be a
waste of time - would you anticipate doing any/much Struts 1.x
development in this scenario?


As for continuing to develop Struts Action 1.x, I imagine not everyone will move 
to Struts Action 2.0, particularly, if they have legacy applications.  I'd even 
guess we'd have committers who still want to work with 1.x, just as Shale didn't 
automatically suck up all the Struts Action 1.x development work.  I know as I 
go back to add features to my legacy Struts applications, I might want to add a 
feature or two that I've enjoyed from Struts Action 2.0.


Don


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

Re: Tough Questions on Struts and Webwork Integration

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
> First, we bring in the WebWork 2.2 code which forms the Struts Ti core.
>  Then, we develop a Struts compatibility layer.  Along the way, if we
> see anything from Struts Action 1.x that should also go into Struts Ti
> core, we can add it.  Honestly, I don't really see anything of Struts
> Action 1.x that isn't done better in WebWork, so yes, I still think it
> is a merger, but being this is targetted for Struts Action 2.0, I think
> it is appropriate to be such a large rewrite.  Even if we wrote Struts
> Action 2.0 from scratch, I doubt we'd see much from Struts Action 1.x
> we'd want to carry over.

Its probably a great plan to switch to WebWork 2.2 but I still don't
see how you can say its a "merger" if no Struts code is involved -
merger in terms of community, but not software.

> And as with WebWork 1.x and as we've been saying from the beginning,
> Struts Action 1.x will continue to be developed and supported, so I
> wouldn't even call that a deprecation.

If its agreed we move to WebWork 2.2 for Struts 2.0 then why would we
continue developing Struts 1.x? I wouldn't want to, it would be a
waste of time - would you anticipate doing any/much Struts 1.x
development in this scenario?

> But again, that is my 2c which may not reflect the opinions of the
> Struts PMC as a whole.
>
> Don
>
> Niall Pemberton wrote:
> > On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:
> > 
> >
> >>>3) A users has invested his or her hard-earned cash in `WebWork' in Action 
> >>>book.
> >>>Will contents of this tome still be relevant in Struts?
> >>
> >>Absolutely, since Struts Ti == WebWork 2.2, with some package name changes.
> >>
> >
> > 
> >
> > 
> >
> >>>5) What architectural components are going to be replaced in Struts ?
> >>>( And conversely in Webwork?)
> >>
> >>This is a tough question because we haven't started on the Struts
> >>compatibility layer so I can't tell you what we can support from Struts.
> >> WebWork will be imported as is, so I don't see anything replaced there
> >>initially, however, we might decide to remove some deprecations.
> >>
> >>I can tell you it is my personal goal for the Struts compatibility layer
> >>to support to some extent Struts Actions, ActionForms, Validator, and
> >>Tiles at least.
> >
> > 
> >
> > I thought the proposal was to merge Struts and WebWork - from this and
> > what : Jason Carreira said on TSS the actual proposal is that Struts
> > Action/Classic is dumped and a migration path for Struts users to
> > WebWork 2.2 be provided?
> >
> > If this is the case then rather than calling this a proposed merger
> > wouldn't it be clearer to say that the proposal is to "deprecate
> > Struts in favour of WebWork"?
> >
> > Niall
> >
> >
> >>Don

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

Re: Tough Questions on Struts and Webwork Integration

Actually, I'd love for Shale and Struts Ti to collaborate more, and in a 
perfect world, both depend on the same core.  Struts Ti won't be 
JSF-specific (ever), but that doesn't mean it can't integrate with JSF. 
 I'm looking forward to ApacheCon so we can sit down with Craig and 
look at ways we can work together better.  Put simply, I fully expect 
Struts Ti to support JSF, and hopefully Shale, in the future in some form.


Don

netsql wrote:
idealy ... it be great to bolt on webwork and ti features on top of 
Shale code base, or at worst fork Shale as a starting point.


there I said it!

.V


-
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: Tough Questions on Struts and Webwork Integration

First, we bring in the WebWork 2.2 code which forms the Struts Ti core. 
 Then, we develop a Struts compatibility layer.  Along the way, if we 
see anything from Struts Action 1.x that should also go into Struts Ti 
core, we can add it.  Honestly, I don't really see anything of Struts 
Action 1.x that isn't done better in WebWork, so yes, I still think it 
is a merger, but being this is targetted for Struts Action 2.0, I think 
it is appropriate to be such a large rewrite.  Even if we wrote Struts 
Action 2.0 from scratch, I doubt we'd see much from Struts Action 1.x 
we'd want to carry over.


And as with WebWork 1.x and as we've been saying from the beginning, 
Struts Action 1.x will continue to be developed and supported, so I 
wouldn't even call that a deprecation.


But again, that is my 2c which may not reflect the opinions of the 
Struts PMC as a whole.


Don

Niall Pemberton wrote:

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:



3) A users has invested his or her hard-earned cash in `WebWork' in Action book.
Will contents of this tome still be relevant in Struts?


Absolutely, since Struts Ti == WebWork 2.2, with some package name changes.








5) What architectural components are going to be replaced in Struts ?
( And conversely in Webwork?)


This is a tough question because we haven't started on the Struts
compatibility layer so I can't tell you what we can support from Struts.
WebWork will be imported as is, so I don't see anything replaced there
initially, however, we might decide to remove some deprecations.

I can tell you it is my personal goal for the Struts compatibility layer
to support to some extent Struts Actions, ActionForms, Validator, and
Tiles at least.




I thought the proposal was to merge Struts and WebWork - from this and
what : Jason Carreira said on TSS the actual proposal is that Struts
Action/Classic is dumped and a migration path for Struts users to
WebWork 2.2 be provided?

If this is the case then rather than calling this a proposed merger
wouldn't it be clearer to say that the proposal is to "deprecate
Struts in favour of WebWork"?

Niall



Don



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




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

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread netsql

idealy ... it be great to bolt on webwork and ti features on top of 
Shale code base, or at worst fork Shale as a starting point.


there I said it!

.V


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

Re: Tough Questions on Struts and Webwork Integration

On 11/29/05, Don Brown <[EMAIL PROTECTED]> wrote:

> > 3) A users has invested his or her hard-earned cash in `WebWork' in Action 
> > book.
> > Will contents of this tome still be relevant in Struts?
>
> Absolutely, since Struts Ti == WebWork 2.2, with some package name changes.
>

> > 5) What architectural components are going to be replaced in Struts ?
> > ( And conversely in Webwork?)
>
> This is a tough question because we haven't started on the Struts
> compatibility layer so I can't tell you what we can support from Struts.
>  WebWork will be imported as is, so I don't see anything replaced there
> initially, however, we might decide to remove some deprecations.
>
> I can tell you it is my personal goal for the Struts compatibility layer
> to support to some extent Struts Actions, ActionForms, Validator, and
> Tiles at least.

I thought the proposal was to merge Struts and WebWork - from this and
what : Jason Carreira said on TSS the actual proposal is that Struts
Action/Classic is dumped and a migration path for Struts users to
WebWork 2.2 be provided?

If this is the case then rather than calling this a proposed merger
wouldn't it be clearer to say that the proposal is to "deprecate
Struts in favour of WebWork"?

Niall

>
> Don

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

Re: Tough Questions on Struts and Webwork Integration

These are some great questions, and particularly relevant to me as I'm 
working on the 2ed edition of Struts in Action.  You can be sure our 
book will cover, at least in part, Struts Ti.  Here is my 2c:


Pilgrim, Peter wrote:

Hi

1) Is the WebWork name going to exist still?


No, at least not in Apache Struts.  The WebWork project will probably 
stick around supporting 1.x and possibly to host migration code.



2) Is the Struts name going to be annexed with WebWork?


Nope.  While initially, this WebWork import will be called Struts Ti, it 
is my hope it will quickly be accepted as Struts Action 2.0.



3) A users has invested his or her hard-earned cash in `WebWork' in Action book.
Will contents of this tome still be relevant in Struts?


Absolutely, since Struts Ti == WebWork 2.2, with some package name changes.

4) In fact there are a number of such books on the markets e.g Struts Receipes 
and Struts Cookbook. Are these book becoming irrevelant or still revelant? 
Have the book publishers lost a dosh of cash, then ?


These books will continue to be important due to:
1. All the existing Struts Action 1.x applications out there
2. The Struts Action 1.x will continue to be supported and developed

Just because there might be a Struts Action 2.0, doesn't mean 
development or support will stop on 1.x.  WebWork itself is a good 
example of this as their 1.x community is still quite alive.



5) What architectural components are going to be replaced in Struts ?
( And conversely in Webwork?)


This is a tough question because we haven't started on the Struts 
compatibility layer so I can't tell you what we can support from Struts. 
 WebWork will be imported as is, so I don't see anything replaced there 
initially, however, we might decide to remove some deprecations.


I can tell you it is my personal goal for the Struts compatibility layer 
to support to some extent Struts Actions, ActionForms, Validator, and 
Tiles at least.



6) What happens to the custom tag libraries like HTML or HTML-EL?


These, of course, will still be supported by Struts 1.x.  We might find 
it possible to simulate them with the Struts compatibility layer, I 
don't know yet.  Still, I think you'll really like the WebWork tags 
since they support multiple template technologies (JSP, Velocity, 
FreeMarker, etc) and have "themes" which include an Ajax theme that uses 
Dojo.



7) Will Struts users suddenly now have to learn OGNL thing?


Struts 1.x users, of course, won't, and while initially Struts Ti users 
will, one of our goals in Struts Ti has been to make that pluggable so 
you could stick JSP EL there or even XPath.



8) How will the Webwork Integration affect popular Struts extensions such as 
the Validator or Tiles?


Again, it is my goal the compatibility layer or even Struts Ti itself 
will support them.  To be honest, I'm not to keen on making Validator 
support core, because I personally think there are better ways to do 
validation, but Tiles will be important to support.  There is a version 
of Tiles that is being worked on which doesn't require Struts at all, so 
it is possible it could be easily used with Struts Ti.


9) A Girl named Geraldine (or A Guy named Gerald if you are so inclined) has invested in 
heavily Spring supported Struts Actions, and has read your recent announcement and 
she proclaims "What Do I Do Now?!"


Keep on keeping on.  I too have a Struts Action 1.x application that 
uses Spring-supported Actions and plan to be supporting it for a while. 
 Struts Ti, if she was interested in it for new apps, will contain 
heavy Spring integration which might be a better choice.



( Spring support AOP already, so does it fit with the WebWork interceptors? )


Two different things, really, so yes, they compliment each other well.


10) "What does WebWork really bring to the Struts party? "
"What is the different between that and this new Struts Ti that I have been hearing 
about?"


WebWork, from a developer and user point of view, is a great framework 
that is well designed, and basically most things I wish Struts was. 
Struts Ti started as a annotation-driven Ruby on Rails-type framework 
which was built on WebWork, however, we are moving some of those 
advanced features back to "phase 2" and making phase 1 the WebWork 
import with Struts compatibility tools.



11) What will be the typically code that the application developer writes for 
Struts 2.x?
Will it be Struts Action, Chains of Commands, or Interceptor?


WebWork too has Actions, however, they view Actions as Struts Actions + 
ActionForms, which I might add, Craig himself sees as a better way to go 
as reflected in JSF.  Furthermore, Actions are request-scoped, so no 
more worrying about thread safety.  We hope to add commons-chain 
integration at least at the global level, however, I'm sure Ted will 
spur integration at the Action level as well :)



12) When do you expect Struts 2.x to "go live"?


When it's ready of course. :)  The WebWork g

RE: Tough Questions on Struts and Webwork Integration

> -Original Message-
> From: Sean Schofield [mailto:[EMAIL PROTECTED]
====

> 
> I have a few thoughts on this and I will try to avoid the "Which
> framework is better?" discussion.
> 
> Change is inevitable.  Struts (as you know and use it today) will
> eventually become obsolete.  Nobody can say when the last meaningful
> Struts 1.x application will be written but that day will eventually
> come.  The great thing about open source is that Darwin decides how
> and when these shifts will happen.  Nobody will force anyone to do
> anything.

Until something that comes a long that is universally available and
is better. Some people will have to develop ( maintain ) those 
Struts 1.x applications

> 
> As for the publishers, I could care less.  I am in the business of
> writing software and I will use the best tools at my disposal to do
> that.  I suspect that the pubishers actually come out ahead in this
> scenario.  Instead of a 3rd edition of a Struts book they can write
> 1st editions of JSF, Spring, Shale, WebWork, etc. books.  My last
> Struts book was Ted's excellent Struts in Action a few years ago.  On
> the other hand, I bought four JSF books this year.

So it does not matter to you about the architecture, either front
controller or page controller? You will use whatever is more 
productive for you?

> 
> My advice is not to be afraid to try something new.  I studied JSF on
> several different occasions and kept deciding against it.  Finally I
> took another long hard look and decided to make a serious attempt at
> understanding it.  As with any new framework, there have been bumps,
> but the payoff is with the second and third applications that you
> write.  Just remember where you were before Struts.  You were probably
> just fine dealing with plain old JSP and Servlets.  At some point the
> promise of "a better way" became too much to resist.  I think the same
> will happen to Struts (in its current form.)
> 

Which is why the integration with WebWork really caught my eye.

I think there are two garden paths here. 

1) The path that follows the standards (JSF) and tooling.
(Sean this is the path you have clear taken.)

2) The path that does not follow the standard, and there are very
good alternatives for not doing so. WebWork, Struts, Wicket, 
Tapestry, Ruby on Rails are examples of the non-standard mission.
(This is the path I am for now until suddenly there is a
JSF project for me on the horizon)

If WebWork/Struts is to succeed then I feel that it must provide
some compelling features or advantages that makes it viable 
competitor. This is just my own observation, and this is 
why I asked what does WebWork bring to party. Effective Sean
you are right about Darwin and biology, effective two different
strands are attempting to rejoin, and everyone would like it to
be successful. The question has got to be right.

Part of the clue will be probably a programming model that does 
not necessarily depend on tools. Commando style development
like editing with vi with the power of a dynamic language
like python or groovy. You should be able write some code in an 
evening and it just works as expected. None of this configuration
of LookupDispatchAction nonsense. So I think productivity and
ease of development will be key.

> Its time to shake things up some.  The Struts community is somewhat
> divided on what the next step should be, but most agree that the
> status quo holds little promise.  There is a huge Struts community
> that will continue to support the 1.x framework for years to come. 
> But many developers like myself are starting to explore "a better
> way."
> 
> sean

You bet

> 
> 
> On 11/29/05, Marky Goldstein <[EMAIL PROTECTED]> wrote:
> > Hi Peter,
> >
> > I guess bringing together the masterminds of multiple
> > web frameworks is a good idea, even if there is a
> > transition phase and some blood that flows...
> > it will make Java as a web platform much stronger.
> >
> > Best regards,
> > Marky
====

--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston, 
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==

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

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

On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
> > Niall Pemberton wrote:
> > > Also looked like the property types were the wrong way round for
> > > indexed methods, so I also switched them.
> >
> > Hmm, with that change, accessing a List property is broken. Without the
> > change, all my tests are working. You can deploy the exercises app with
> > the addition I just committed and see for yourself:
> >   http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do
> >
> > I've rolled back your change and everything works fine again, including
> > indexed property access for arrays and lists. The unit test you added
> > passes either way.
>
> I just refreshed and the JUnit test I wrote is now failing for me.

Its failing in gump as well
http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html

I've had problems with the maven build - when I've used build-all if a
sub-project test fails maven just carries on ignoring it and it
appears you get a successful build. Now I do the sub-projects
separately.

I'm wondering if thats what you used?

Niall

> Niall
>
> > If you think there's a scenario not covered by the exercises page that
> > would be broken with the original code let me know and I'll look into it
> > further.
> >
> > L.
>

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

RE: Tough Questions on Struts and Webwork Integration


> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
====
> 
> 
> By no means do I consider myself the authority to answer these, but 
> here are some responses based on my understanding and my interest in 
> how things go.  In summary, really a lot of these questions are 
> premature based on the likely pace of development, and as always, the 
> community is going to set the direction based on who steps up to 
> participate in the coding.  That said, here are point-by-points...
> 

I agree some of these questions are premature. I felt the urge
to ask with some kind of quasi-journalistic verge, because
it is better to have clarity of where Java web technology
is going.

> >1) Is the WebWork name going to exist still?
> 
> I don't think so.
> 
> >2) Is the Struts name going to be annexed with WebWork?
> 
> I don't think so.
> 

So in fact WebWork is going to be subsumed under Struts umbrella.
That is fine, but I wonder is this going to upset the WebWorkers?

> >3) A users has invested his or her hard-earned cash in `WebWork' in 
> >Action book.
> >Will contents of this tome still be relevant in Struts?
> 
> Substantially yes, although of course there will be package naming 
> changes and whatever changes seem to make for a better framework.
> 


> >4) In fact there are a number of such books on the markets 
> e.g Struts Receipes
> >and Struts Cookbook. Are these book becoming irrevelant or 
> still revelant?
> >Have the book publishers lost a dosh of cash, then ?
> 
> I think that no publisher expects to be making a lot from tech books 
> for very long after they are published; things just change too fast. 
> In any case, that's not my concern, and it wouldn't be even if I had 
> written one of those books ;-)
> 
If you go to conferences then one of the selling points for users
is to buy the book that goes with the latest technology. So I believe
it is of concern to the potential users, if not directly the publishers
themselves.


> >5) What architectural components are going to be replaced in Struts ?
> >( And conversely in Webwork?)
> 
> TBD
>

I assume, then, that the next Struts will probably follow the FrontController
design pattern. However is this true, or is it going to be 
a new architecture? 
 
> >6) What happens to the custom tag libraries like HTML or HTML-EL?
> 
> TBD
> 
> >7) Will Struts users suddenly now have to learn OGNL thing?
> 
> That seemed to be on the roadmap.  It also didn't seem to be 
> a big burden.
> 
> >8) How will the Webwork Integration affect popular Struts extensions 
> >such as the Validator or Tiles?
> 
> Both are (or are being adapted to be) able to run without Struts. 
> Therefore, they should be usable or not as is deemed of use to the 
> community.  Odds seem good that some kind of adapters will be 
> available.
> 

Fair enough

> >9) A Girl named Geraldine (or A Guy named Gerald if you are so 
> >inclined) has invested in
> >heavily Spring supported Struts Actions, and has read your recent 
> >announcement and
> >she proclaims "What Do I Do Now?!"
> >
> >( Spring support AOP already, so does it fit with the 
> WebWork interceptors? )
> 
> Well, as always, there's no reason to jump to the new thing if it 
> doesn't serve your needs.  Are there things that you really find 
> harder than they should be now that you have this Struts-and-Spring 
> framework in place?  If not, why switch?  If so, help map the path 
> from where you are to where you want to be and you'll be more able to 
> ensure continuity!  (See also 11 below.)
> 

I guess you're right. If there's an itch, it will be probably
be scratched.

The other side of the coin is that of simplification. 
One of the short falls of Struts and Java web is you already find
yourself hand-injecting or binding stuff altogether. 
If the next version of Struts is able to simplify development 
then that will be a big-win.


> 
> >10) "What does WebWork really bring to the Struts party? "
> >"What is the different between that and this new Struts Ti that I 
> >have been hearing about?"
> 
> The main difference between this and Struts Ti is that rather than 
> including WebWork as a dependency, it will be included in the 
> distribution.  This allows for more efficient management of 
> interrelationships between the core and the layers that Ti was 
> offering to bring above and beyond what WebWork already has.
>
Good
 
> >11) What will be the typically code that the application developer 
> >writes for Struts 2.x?
> >Will it be Struts Action, Chains of Commands, or Interceptor?
> 
> I imagine that all of them will be usable.  The differences are 
> pretty superficial really.  I imagine that we will try to leave the 
> plug-in point for control logic as wide open as possible.  There are 
> many ways to skin that cat and no need to insist on the one-true-way.
> 
> >12) When do you expect Struts 2.x to "go live"?
> 
> Peter!  You've been around here long enough to know better! ;-)
> 
Yep, I know, just

Re: display wrong german chars

2005-11-29 Thread C. Grobmeier


Hello Michele,

guess you need to read about this html tags:



Here is useful link:

* http://de.selfhtml.org/html/kopfdaten/meta.htm#zeichenkodierung
It's in german.

I think you should post these kind of questions in the struts-user list.
This is a list for developing struts itself.

Cheers,
Chris

Michele Sferlazza wrote:

My validator returns with wrong character in the case of an error.
The form fields display the wrong character.
I need the German character set (UTF-8). Someone can help me?

thanks
michele

-
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: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Sean Schofield

I have a few thoughts on this and I will try to avoid the "Which
framework is better?" discussion.

Change is inevitable.  Struts (as you know and use it today) will
eventually become obsolete.  Nobody can say when the last meaningful
Struts 1.x application will be written but that day will eventually
come.  The great thing about open source is that Darwin decides how
and when these shifts will happen.  Nobody will force anyone to do
anything.

As for the publishers, I could care less.  I am in the business of
writing software and I will use the best tools at my disposal to do
that.  I suspect that the pubishers actually come out ahead in this
scenario.  Instead of a 3rd edition of a Struts book they can write
1st editions of JSF, Spring, Shale, WebWork, etc. books.  My last
Struts book was Ted's excellent Struts in Action a few years ago.  On
the other hand, I bought four JSF books this year.

My advice is not to be afraid to try something new.  I studied JSF on
several different occasions and kept deciding against it.  Finally I
took another long hard look and decided to make a serious attempt at
understanding it.  As with any new framework, there have been bumps,
but the payoff is with the second and third applications that you
write.  Just remember where you were before Struts.  You were probably
just fine dealing with plain old JSP and Servlets.  At some point the
promise of "a better way" became too much to resist.  I think the same
will happen to Struts (in its current form.)

Its time to shake things up some.  The Struts community is somewhat
divided on what the next step should be, but most agree that the
status quo holds little promise.  There is a huge Struts community
that will continue to support the 1.x framework for years to come. 
But many developers like myself are starting to explore "a better
way."

sean

On 11/29/05, Marky Goldstein <[EMAIL PROTECTED]> wrote:
> Hi Peter,
>
> I guess bringing together the masterminds of multiple
> web frameworks is a good idea, even if there is a
> transition phase and some blood that flows...
> it will make Java as a web platform much stronger.
>
> Best regards,
> Marky
>
>
> Pilgrim, Peter wrote:
>
> >Hi
> >
> >1) Is the WebWork name going to exist still?
> >
> >
> >
> >2) Is the Struts name going to be annexed with WebWork?
> >
> >
> >
> >3) A users has invested his or her hard-earned cash in `WebWork' in Action 
> >book.
> >Will contents of this tome still be relevant in Struts?
> >
> >
> >
> >4) In fact there are a number of such books on the markets e.g Struts 
> >Receipes
> >and Struts Cookbook. Are these book becoming irrevelant or still revelant?
> >Have the book publishers lost a dosh of cash, then ?
> >
> >
> >
> >5) What architectural components are going to be replaced in Struts ?
> >( And conversely in Webwork?)
> >
> >
> >
> >
> >6) What happens to the custom tag libraries like HTML or HTML-EL?
> >
> >
> >
> >
> >7) Will Struts users suddenly now have to learn OGNL thing?
> >
> >
> >
> >8) How will the Webwork Integration affect popular Struts extensions such as 
> >the Validator or Tiles?
> >
> >
> >
> >9) A Girl named Geraldine (or A Guy named Gerald if you are so inclined) has 
> >invested in
> >heavily Spring supported Struts Actions, and has read your recent 
> >announcement and
> >she proclaims "What Do I Do Now?!"
> >
> >( Spring support AOP already, so does it fit with the WebWork interceptors? )
> >
> >
> >
> >10) "What does WebWork really bring to the Struts party? "
> >"What is the different between that and this new Struts Ti that I have been 
> >hearing about?"
> >
> >
> >
> >11) What will be the typically code that the application developer writes 
> >for Struts 2.x?
> >Will it be Struts Action, Chains of Commands, or Interceptor?
> >
> >
> >12) When do you expect Struts 2.x to "go live"?
> >
> >
> >References:
> >
> >http://www.theserverside.com/news/thread.tss?thread_id=37794
> >
> >http://blogs.opensymphony.com/webwork/
> >
> >http://www.manning.com/books/lightbody
> >
> >
> >--
> >Peter Pilgrim :: J2EE Software Development
> >Operations/IT - Credit Suisse First Boston,
> >Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
> >Tel: +44-(0)207-883-4497
> >
> >
> >==
> >Please access the attached hyperlink for an important electronic 
> >communications disclaimer:
> >
> >http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
> >
> >==
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> --
> R.Ø.S.A.
> Identity: Marky Goldstein
> E-Mail: [EMAIL PROTECTED]
> Task: Managing Director, Product & Strategy
>
> R.Ø.S.A. Creation. Technology. Intelligence. AG
> Seefeldstrasse 231, 8008 Zurich, Switzerland
> Phone: +41 1 389 6

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Marky Goldstein


Hi Peter,

I guess bringing together the masterminds of multiple
web frameworks is a good idea, even if there is a
transition phase and some blood that flows...
it will make Java as a web platform much stronger.

Best regards,
Marky


Pilgrim, Peter wrote:


Hi

1) Is the WebWork name going to exist still?



2) Is the Struts name going to be annexed with WebWork?



3) A users has invested his or her hard-earned cash in `WebWork' in Action book.
Will contents of this tome still be relevant in Struts?



4) In fact there are a number of such books on the markets e.g Struts Receipes 
and Struts Cookbook. Are these book becoming irrevelant or still revelant? 
Have the book publishers lost a dosh of cash, then ?




5) What architectural components are going to be replaced in Struts ?
( And conversely in Webwork?)




6) What happens to the custom tag libraries like HTML or HTML-EL?




7) Will Struts users suddenly now have to learn OGNL thing?



8) How will the Webwork Integration affect popular Struts extensions such as 
the Validator or Tiles?



9) A Girl named Geraldine (or A Guy named Gerald if you are so inclined) has invested in 
heavily Spring supported Struts Actions, and has read your recent announcement and 
she proclaims "What Do I Do Now?!"


( Spring support AOP already, so does it fit with the WebWork interceptors? )



10) "What does WebWork really bring to the Struts party? "
"What is the different between that and this new Struts Ti that I have been hearing 
about?"



11) What will be the typically code that the application developer writes for 
Struts 2.x?
Will it be Struts Action, Chains of Commands, or Interceptor?


12) When do you expect Struts 2.x to "go live"?


References:

http://www.theserverside.com/news/thread.tss?thread_id=37794

http://blogs.opensymphony.com/webwork/

http://www.manning.com/books/lightbody


--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston, 
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom

Tel: +44-(0)207-883-4497


==
Please access the attached hyperlink for an important electronic communications disclaimer: 


http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==


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

 




--
R.Ø.S.A.
Identity: Marky Goldstein
E-Mail: [EMAIL PROTECTED]
Task: Managing Director, Product & Strategy

R.Ø.S.A. Creation. Technology. Intelligence. AG
Seefeldstrasse 231, 8008 Zurich, Switzerland
Phone: +41 1 389 63 33
Fax: +41 1 389 63 30
URL: http://www.rosa.com/ 




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

Re: Tough Questions on Struts and Webwork Integration

2005-11-29 Thread Joe Germuska

By no means do I consider myself the authority to answer these, but 
here are some responses based on my understanding and my interest in 
how things go.  In summary, really a lot of these questions are 
premature based on the likely pace of development, and as always, the 
community is going to set the direction based on who steps up to 
participate in the coding.  That said, here are point-by-points...



1) Is the WebWork name going to exist still?


I don't think so.


2) Is the Struts name going to be annexed with WebWork?


I don't think so.

3) A users has invested his or her hard-earned cash in `WebWork' in 
Action book.

Will contents of this tome still be relevant in Struts?


Substantially yes, although of course there will be package naming 
changes and whatever changes seem to make for a better framework.



4) In fact there are a number of such books on the markets e.g Struts Receipes
and Struts Cookbook. Are these book becoming irrevelant or still revelant?
Have the book publishers lost a dosh of cash, then ?


I think that no publisher expects to be making a lot from tech books 
for very long after they are published; things just change too fast. 
In any case, that's not my concern, and it wouldn't be even if I had 
written one of those books ;-)



5) What architectural components are going to be replaced in Struts ?
( And conversely in Webwork?)


TBD


6) What happens to the custom tag libraries like HTML or HTML-EL?


TBD


7) Will Struts users suddenly now have to learn OGNL thing?


That seemed to be on the roadmap.  It also didn't seem to be a big burden.

8) How will the Webwork Integration affect popular Struts extensions 
such as the Validator or Tiles?


Both are (or are being adapted to be) able to run without Struts. 
Therefore, they should be usable or not as is deemed of use to the 
community.  Odds seem good that some kind of adapters will be 
available.


9) A Girl named Geraldine (or A Guy named Gerald if you are so 
inclined) has invested in
heavily Spring supported Struts Actions, and has read your recent 
announcement and

she proclaims "What Do I Do Now?!"

( Spring support AOP already, so does it fit with the WebWork interceptors? )


Well, as always, there's no reason to jump to the new thing if it 
doesn't serve your needs.  Are there things that you really find 
harder than they should be now that you have this Struts-and-Spring 
framework in place?  If not, why switch?  If so, help map the path 
from where you are to where you want to be and you'll be more able to 
ensure continuity!  (See also 11 below.)




10) "What does WebWork really bring to the Struts party? "
"What is the different between that and this new Struts Ti that I 
have been hearing about?"


The main difference between this and Struts Ti is that rather than 
including WebWork as a dependency, it will be included in the 
distribution.  This allows for more efficient management of 
interrelationships between the core and the layers that Ti was 
offering to bring above and beyond what WebWork already has.


11) What will be the typically code that the application developer 
writes for Struts 2.x?

Will it be Struts Action, Chains of Commands, or Interceptor?


I imagine that all of them will be usable.  The differences are 
pretty superficial really.  I imagine that we will try to leave the 
plug-in point for control logic as wide open as possible.  There are 
many ways to skin that cat and no need to insist on the one-true-way.



12) When do you expect Struts 2.x to "go live"?


Peter!  You've been around here long enough to know better! ;-)

Joe

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex


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

Tough Questions on Struts and Webwork Integration


Hi

1) Is the WebWork name going to exist still?



2) Is the Struts name going to be annexed with WebWork?



3) A users has invested his or her hard-earned cash in `WebWork' in Action book.
Will contents of this tome still be relevant in Struts?



4) In fact there are a number of such books on the markets e.g Struts Receipes 
and Struts Cookbook. Are these book becoming irrevelant or still revelant? 
Have the book publishers lost a dosh of cash, then ?



5) What architectural components are going to be replaced in Struts ?
( And conversely in Webwork?)




6) What happens to the custom tag libraries like HTML or HTML-EL?




7) Will Struts users suddenly now have to learn OGNL thing?



8) How will the Webwork Integration affect popular Struts extensions such as 
the Validator or Tiles?



9) A Girl named Geraldine (or A Guy named Gerald if you are so inclined) has 
invested in 
heavily Spring supported Struts Actions, and has read your recent announcement 
and 
she proclaims "What Do I Do Now?!"

( Spring support AOP already, so does it fit with the WebWork interceptors? )



10) "What does WebWork really bring to the Struts party? "
"What is the different between that and this new Struts Ti that I have been 
hearing about?"



11) What will be the typically code that the application developer writes for 
Struts 2.x?
Will it be Struts Action, Chains of Commands, or Interceptor?


12) When do you expect Struts 2.x to "go live"?


References:

http://www.theserverside.com/news/thread.tss?thread_id=37794

http://blogs.opensymphony.com/webwork/

http://www.manning.com/books/lightbody


--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston, 
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497


==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==


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

[EMAIL PROTECTED]: Project struts-action (in module struts) failed

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-action has an issue affecting its community integration.
This issue affects 85 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-faces :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-portal-sample :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- commons-jelly-tags-ojb :  Commons Jelly
- commons-jelly-tags-quartz :  Commons Jelly
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- fulcrum-quartz :  Services Framework
- fulcrum-security-adapter-turbine :  Services Framework
- jakarta-tomcat-5 :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- jakarta-velocity-tools :  Velocity-Tools project
- lenya :  Content Management System
- myfaces :  JavaServer(tm) Faces implementation
- portals-bridges-frameworks :  Support for JSR168 compliant Portlet 
development
- portals-bridges-jsf :  Support for JSR168 compliant Portlet development
- portals-bridges-struts :  Support for JSR168 compliant Portlet development
- portals-bridges-velocity :  Support for JSR168 compliant Portlet 
development
- portals-jetspeed-1 :  Enterprise Information Portal
- quartz :  Job Scheduler
- smartfrog-tomcat :  Smartfrog: Application Deployment from HP Laboratories
- struts-action :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-el :  Model 2 Model-View-Controller framework for Servlets and JSP
- struts-sslext :  The Struts SSL Extension for HTTP/HTTPS switching
- struts-taglib :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-tiles :  Model 2 Model-View-Contr

[EMAIL PROTECTED]: Project struts-action (in module struts) failed

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-action has an issue affecting its community integration.
This issue affects 85 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon :  Java XML Framework
- cocoon-block-ajax :  Ajax - Utilities and resources for Ajax applications.
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-captcha :  Utilites to generate simple CAPTCHAs
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-core-samples-additional :  Additional core samples.
- cocoon-block-core-samples-main :  Main core samples.
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-faces :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jcr :  A "jcr:" protocol for Cocoon
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-portal-sample :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-querybean :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-scratchpad :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-spring-app :  A demo for Spring and Cocoon
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-template :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-validation :  In-pipeline validation of documents
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- commons-jelly-tags-ojb :  Commons Jelly
- commons-jelly-tags-quartz :  Commons Jelly
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- forrest :  Apache Forrest is an XML standards-oriented documentation fr...
- forrest-test :  Apache Forrest is an XML standards-oriented documentation 
fr...
- fulcrum-quartz :  Services Framework
- fulcrum-security-adapter-turbine :  Services Framework
- jakarta-tomcat-5 :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- jakarta-velocity-tools :  Velocity-Tools project
- lenya :  Content Management System
- myfaces :  JavaServer(tm) Faces implementation
- portals-bridges-frameworks :  Support for JSR168 compliant Portlet 
development
- portals-bridges-jsf :  Support for JSR168 compliant Portlet development
- portals-bridges-struts :  Support for JSR168 compliant Portlet development
- portals-bridges-velocity :  Support for JSR168 compliant Portlet 
development
- portals-jetspeed-1 :  Enterprise Information Portal
- quartz :  Job Scheduler
- smartfrog-tomcat :  Smartfrog: Application Deployment from HP Laboratories
- struts-action :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-el :  Model 2 Model-View-Controller framework for Servlets and JSP
- struts-sslext :  The Struts SSL Extension for HTTP/HTTPS switching
- struts-taglib :  Model 2 Model-View-Controller framework for Servlets and 
JSP
- struts-tiles :  Model 2 Model-View-Contr

display wrong german chars

2005-11-29 Thread Michele Sferlazza

My validator returns with wrong character in the case of an error.
The form fields display the wrong character.
I need the German character set (UTF-8). Someone can help me?

thanks
michele

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

DO NOT REPLY [Bug 37685] New: - Javascript tag does not work on Mozilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: Javascript tag does not work on Mozilla
   Product: Struts
   Version: 1.2.8
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P1
 Component: Custom Tags
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


To checks that validation succeeded, 
org.apache.struts.taglib.html.JavascriptValidatorTag writes this code:
"return (formValidationResult == 1);"
But on Mozilla 1.7.11, this return false if formValidationResult  == true.
This code should be replaced by "return (formValidationResult === true);"
To check this try this code on different browsers:



function test()
{
var test = (2==2) && (1 == 1);
alert('test='+test);
alert('test==1'+(test==1));
alert('test===true'+(test===true));
}



Here



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37683] New: - document permitted form field names and provide a validation method