RE: [action2] Towards our first release

[Pilgrim, Peter]

> -Original Message-
> From: Don Brown [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 21, 2006 12:23 AM
> To: Struts Developers List
> Subject: [action2] Towards our first release
> 
> 
> At JavaOne, Patrick, Jason, and I will be presenting a 
> session about Struts Action 2 (deceptively titled, "What's Up 
> with Struts Ti?")  We definitely want to have something more 
> concrete to talk about like at least an unstable release of 
> Struts Action 2.  JavaOne runs May 16-19 and our session is 
> on May 17 at 2:45 PM.
> 

Cool! I will be in attendance. 

--
Peter Pilgrim :: J2EE Software Development & Architecture
Operations/IT - Credit Suisse Group - "One Bank",
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
 peter dot pilgrim at credit-suisse.com 

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

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==


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

RE: [ANN] JAVAWUG BOF XVII / Friday 28th April 2006 @ 19:00 / Ora cle City of London

[Pilgrim, Peter]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Peter Pilgrim

====

> 
> Dear All
> 
> The JAVAWUG (Java Web User Group) has rescheduled the BOF 
> XVIII (Number 
> 17) from Thursday 20th April to now Friday 20th April 2006.


 +
This should have said+  Friday, 28th April 2006  +
 +


> 
> The birds-of-feather will still take place at the same venue, 
> Oracle's 
> City of London office between 7-9:30 pm. The presentations are and
> the confirmed speakers are:
> 
> 
>   Prashanth, S.
>   ``J2EE: Security on Websphere''
> 
>   Peter Pilgrim
>  ``Experiences With WebWork''
> 

We now have a third volunter speaker:

Mark Burton
``JavaServer Faces: An Overview''


This is a free event.

> Afterwards members can retire to the nearby the ``All Bar One''
> pub/restaurant for more in depth discussion dinner,
> food and drink ...
> 
> The address is:
>  Oracle City Of London
>  One South Place
>  London,
>  England
>  EC2M 2RB.
> 
> 
> >> If you would like to attend, please REGISTER so that you can
> >> be added to the SECURITY DETAIL
> >>
> >> Join the http://groups.google.com/group/javawug JAVAWUG at 
> Google Groups
> >> and ``Send an Email to the list you are attending''
> >>
> >> Alternatively send mail to myself at peter dot pilgrim at 
> credit-suisse.com
> >> and duncan dot mills at oracle.com
> >>
> >> Here is some relevant travel information:
> >>
> >> By Underground: -
> >> Moorgate: Take the Moorgate East exit, turn right, 
> one block to South
> >> Place.
> >> Bank: Take the Northern line to Moorgate.
> >> Liverpool Street: Take the Broadgate exit, turn 
> right onto South Place
> >>
> >>
> >> Map: 
> http://www.oracle.com/global/uk/corporate/locations/citymap.html
> >>
> >> The venue has graciously been organised by Duncan Mills of 
> Oracle Corp.
> >> We all appreciate this generous gift.
> >>
> >> http://www.javawug.com/
> >>
> >> http://jroller.com/page/peter_pilgrim
> >>
> >> PS: The presentations will be recorded and I hope to 
> upload them all
> >> Google Video Site. search against JAVAWUG for the last 
> video uploads.
> >>
> ====
====

--
Peter Pilgrim
Organiser / Founder   ( JAVAWUG  
http://developers.sun.com/jugs/display/europe/gbr/london )
 
   ( ( (  (   (  
   (   )\(   (   )\)\))(   '   (  )\ )   
   )_)(  )\  )_)( ((_)()\ ))\(()/(   
  ((_)\ _ )\((_)((_)\ _ )\_(())\_)()_ ((_)/(_))_ 
 _ | (_)_\(_) \ / /(_)_\(_) \((_)/ / | | (_)) __|
| || |/ _ \  \ V /  / _ \  \ \/\/ /| |_| | | (_ |
 \__//_/ \_\  \_/  /_/ \_\  \_/\_/  \___/   \___|
=

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

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==


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

RE: XWork and Struts Action 2.0

[Pilgrim, Peter]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Bob Lee
> Sent: Tuesday, April 18, 2006 9:56 PM
> To: Struts Developers List; [EMAIL PROTECTED]
> Subject: Re: XWork and Struts Action 2.0
> 
> 
> On 4/18/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> > I would tend to disagree. I feel that the separate of 
> concerns between
> > XWork and a web application front end are important. I don't believe
> > it would be helpful to start lumping things back together again.
> 
> Providing Struts users with a complete, cohesive API doesn't preclude
> this separation.
> 
> > I do think one problem is that our approach to referring to XWork in
> > the WW book and documentation is inconsistent. There is a 
> tendency to
> > refer to everything as WebWork when it is not. Moving 
> forward, I think
> > we simply need to be more carefult to say XWork when we 
> mean XWork and
> > SAF when we mean SAF, and perhaps just refer to "the framework" when
> > we do not care to make the distinction.
> 
> This is exactly what I'm talking about. 99.9% of users (100% of Struts
> users) don't care about this separation, and they have trouble with
> it. Even the authors have trouble keeping it straight.
> 

As a new user of WebWork 2.2 I dont see much of XWork except for the
xwork.xml file. So I agree totally. This is not to say that as an 
advanced user, one day I might decide to exploit an XWork feature.

> > No, Struts Action 2.0 will *not* require Java 1.5. I'm sure some
> > future release will increment the platform, but right now, most
> > everyone I know is using Java 1.4 in production. Action 2.0 is meant
> > to be something that we can all start using in production now.
> 
> Without saying whether we should support 1.4 or not, realistically
> we're talking about Struts 2.0.0 in production some time after August
> depending how long it takes users to port their applications, not
> right now, at this moment, right? JDK 1.6 comes out in the fall at
> which point 1.4 will be two major releases behind. We must embrace
> 1.5. We should keep in mind that:
> 

Keep in mind the corporate business side of things. The Java EE 5.0
specification is still not released yet.

> - 1.4 support will add complexity and require more development time
> - 1.4 will become less relevant pretty quickly
> - 1.4 users have two other options: Struts 1.2 and WebWork 2.2
> 

Of course waiting for Java EE 5.0 and EJB 3.0 holds things up
significantly if you are deploying to WebLogic Server 8.1 which
is halfway to J2EE 1.4 in the first place. In other corporates
cannot make the jump to Java 5 because they are waiting on
Java EE 5.0 application server to be certified! Of course this
may not apply to you if you are using JBoss and/or Tomcat!






--
Peter Pilgrim :: J2EE Software Development & Architecture
Operations/IT - Credit Suisse Group - "One Bank",
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.credit-suisse.com/legal/en/disclaimer_email_ib.html
==


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

[ANN] JAVAWUG BOF XVII / Thursday 20th April 2006 @ 19:00 / Oracl e City of London

[Pilgrim, Peter]

Dear All

I would like to formally announce that JAVAWUG (Java Web User Group) 
is holding the seventeenth Birds-of-Feather (Meet up XVII) at the 
Oracle City of London offices on Thursday, 20th April 2006.

The meeting will take place in a room with Audio/Visual facilities
between 7-9:30 pm. There will be a series of presentations, Quickies,
inspired by the JavaPolis short presentation format.

The confirmed speakers are:

Prashanth, S.
``J2EE: Security on Websphere''

Peter Pilgrim
``Experiences With WebWork''



Afterwards members can retire to the nearby the ``All Bar One'' 
pub/restaurant for more in depth discussion dinner, 
food and drink ...

The address is:
Oracle City Of London
One South Place
London,
England
EC2M 2RB.


If you would like to attend, please REGISTER so that you can
be added to the SECURITY DETAIL

Join the http://groups.google.com/group/javawug JAVAWUG at Google Groups
and ``Send an Email to the list you are attending'' 

Alternatively send mail to myself at peter dot pilgrim at credit-suisse.com 
and duncan dot mills at oracle.com

Here is some relevant travel information: 

By Underground: -
Moorgate: Take the Moorgate East exit, turn right, one block to South 
Place.
Bank: Take the Northern line to Moorgate.
Liverpool Street: Take the Broadgate exit, turn right onto South Place


Map: http://www.oracle.com/global/uk/corporate/locations/citymap.html 

The venue has graciously been organised by Duncan Mills of Oracle Corp. 
We all appreciate this generous gift. 

http://www.javawug.com/

http://jroller.com/page/peter_pilgrim

PS: The presentations will be recorded and I hope to upload them all
Google Video Site. search against JAVAWUG for the last video uploads.



--
Peter Pilgrim :: J2EE Software Development & Architecture
Operations/IT - Credit Suisse Group - "One Bank",
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
 peter dot pilgrim at credit-suisse.com 

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

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==


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

[test] ignore

[Pilgrim, Peter]

Testing using Micro$oft Outlock 200 sp3

I seem to be have problems with my mail sent to google group sent as 7bit  
character set. Just want to prove that apache and sourceforge dont
have to the problem, and eliminate these providers.

--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse Group - "One Bank",
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
 peter dot pilgrim at credit-suisse.com 


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

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==


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

RE: [POLL] Struts Action Framework tagline

[Pilgrim, Peter]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
====
> 
> 
> On 1/11/06, netsql <[EMAIL PROTECTED]> wrote:
> > And... why not Struts, which is what user list calls it, instead of
> > correcting them.
> 
> Because, very shortly, we will be adopting the WebWork code base as
> Struts Action 2.x, and, at the same time marching toward a stable
> release of Struts Action 1.3.x.
> 
> We know that people are going to want to thread conversations by
> Action 1.x or Action 2.x. Better to standardize now and get it over
> with.
 
Why not follow the Maven convention?

Instead of [m1] and [m2] standing for Maven 1.x and Maven 2.x,
why not do the same with Struts action [a1] and [a2]?


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

==
This message is for the named person's use only.  It may contain confidential,
proprietary or legally privileged information.  No confidentiality or 
privilege is waived or lost by any transmission errors. If you receive
this message in error, please immediately delete it and all copies of it from
your system, destroy any hard copies of it and notify the sender.  You must
not, directly or indirectly, use, disclose, distribute, print, or copy any
part of this message if you are not the intended recipient.  
CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to
intercept and monitor all e-mail communications through its networks if 
legally allowed. Message transmission is not guaranteed to be secure.
==


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

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

[Pilgrim, Peter]

> -Original Message-
> From: Don Brown [mailto:[EMAIL PROTECTED]
> Sent: 05 December 2005 05:39
> To: Struts Developers List
> Subject: Re: [ti] Struts Action 1.x migration tools
> 
> 
> I'd classify all those goals as those of approach 1, which is 
> building 
> 1.x support right in Ti.  What I'm coming to the conclusion 
> of is that 
> it would be a lot of work, be prone to surprise errors, and 
> ultimately 
> futile.  If my 1.x app is running fine, what would I gain by 
> trying to 
> run it on a platform (Ti) which is buggy and where my fancy Struts 
> extensions (custom RequestProcessor, tricks using internal 
> Struts APIs, 
> etc) won't work or only work sometimes.
> 
> My approach #2, to include 1.x jars and develop co-existing 
> tools, lets 
> someone run a 1.x app "on" Struts Ti completely unchanged and 
> with 100% 
> functionality, 1.x quirks and all.  I think a user would mainly be 
> interested in that, and perhaps building new segments with Ti as the 
> opportunity arose.
> 
> But perhaps that is a faulty assumption.  What do the rest of 
> you think?
> 
> Don

I see it falling in the second choice, approach #2. I think 
users may like this opinion, because

1) It allows them to "suck it and see" if Struts Ti works for them.
2) It would garner support from key decision makers.
3) There is some kind of transfer of application knowledge to the
next guy or doll who has to maintain /upgrade the Struts apps.


> 
> Laurie Harper wrote:
> 
> > I have to ask if the goal behind 1 through 3 is the right 
> goal... In 
> > other words, should the goal be
> > 
> >  1 - allow a Struts 1.x app to run unchanged on Ti
> >  2 - allow a Struts 1.x app to run unchanged on Ti, w/ some caveats
> >  3 - allow a Struts 1.x app to run on Ti, with only minor changes
> >  4 - allow a Struts 1.x app to run on Ti, with a well defined set of
> >  migration changes, possibly supported by automated tools
> > 
> > I thought there was a general leaning towards something 
> more like 4, 
> > with a corresponding minimization of code in Ti solely for 
> the sake of 
> > 1.x compatibility. IMHO the right balance would be 
> somewhere between 3 
> > and 4; 1 and 2 impose a higher burden on Ti than should be 
> expected or 
> > required of a 'Struts 2.0'.
> > 
====


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

[Pilgrim, Peter]

> -Original Message-
> From: Don Brown [mailto:[EMAIL PROTECTED]
====
> 
> 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.
>

If I understand you rightly the traditional `RequestProcessor' 
derived process flow, namely

ActionServlet => RequestProcessor => Action => View

is gone to be replaced by the WebWork / X Work processing
chain.

If someone has invested in Commons Chain command will they 
be able to quick migrate or directly use Struts 2.x
engine.

Is there an equivalent of the `RequestProcessor' concept in the
webwork/xwork?

> > 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 ;)
> 

Has anyone writen a WebWork introductio guide for experienced
Struts users yet?

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

That's good to know.

> 
> > 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. :)

Ok that's a great idea
> 
> Don
> 



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

[Pilgrim, Peter]

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

RE: Tough Questions on Struts and Webwork Integration

[Pilgrim, Peter]

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

[Pilgrim, Peter]

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

Tough Questions on Struts and Webwork Integration

[Pilgrim, Peter]

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]

RE: Thread-unsafe Command classes

[Pilgrim, Peter]

> -Original Message-
> From: Wolfgang Gehner [mailto:[EMAIL PROTECTED]
> Sent: 24 September 2005 11:06
> To: Struts Developers List
> Subject: Re: Thread-unsafe Command classes
> 
> 
> If I want to use Spring I use Spring MVC, but I think a lot 
> of drive in 
> Struts evolution is to encorporate nice ideas that have come up as 
> techniques elswhere over the last years, see Struts TI. So Struts 
> developers won't *have to* use Spring on top or instead. (I am not 
> convinced that TI should use/depend on Spring).
> 
> I think CoR with Chains is great and simple for declaratively linking 
> things as of Struts 1.3. I also think CoR is a more beautiful pattern 
> than IoC for a lot of people. I also think there is a great bang in 
> using the execute(context) interface rather than 
> execute(mapping, req, 
> res etc). I have written commands rather than actions for 8 
> months now 
> and I don't miss old actions a bit.

Chain of commands do give one the ability to perform "action chaining".
Do you allow the action context to propogate to the background
data access layer or not?

In these day I dont think it makes a lot of difference, because
most of us, I believe, I writing co-located J2EE applications.

In the earlier days, the so-called best practice was to separate
Servlet API from the back end business tier. The reason was
for remote distributed EJB, which apparently just a few were 
actually using in ager. Nowadays everything is bundled in one
EAR for deployment. 

Chaining is a lot more comprehensible for the beginner, because
it is a use-case that many programmers have come across before.
Inverse of control is harder on the brain if you have never done
any event-driven or "callback" style programming where you allow 
the framework manage the lifecycle of your beans and action.

> 
> I still  like the behavior of a class inside the class. When 
> you have an 
> execute hook you probably need less understanding of the class 
> implementation and how possibly inject stuff otherwise. At least not 
> YACF (yet another config file) - cf. Ruby on Rails. Also think of 
> .execute(context) as an entry comparable to a main method.

I did not quite follow the argument "class" within a "class".

I agree with you it is another example of XML hell.

The fly in the ointment is that inverse-of-control is now often
used with aspect orient development. Beans can be intercepted
or transformed if they instantiated from the framework (or indirectly
from an annotation)

> 
> If I need to create an adapter class to run particular logic, 
> I could do 
> that with plain old actions.
> There may still be cases where IoC is really needed, but with 
> Struts 1.3 
> as tool I just I don't come across them that often.
> 

If you want to write a command with transactional or logging
behaviour. then you might run with an IoC / AoP container.

> Another advantage of using the command interface is if I find 
> that some 
> command is generic to an application I can add them to the defautl 
> struts chain, rather than wiring through a custom base-command class. 
> Which really leverages the new chain architecture of Struts! 
> Finally we 
> can change the default behavior of the Struts cycle. It has the 
> potential to wire stuff for all kinds of apps, including remote. Now 
> that's a great bang!
> 
> Could you imagine having rewritten the struts request processor with 
> spring IOC?
> 
> Re the singleton issue: I think you suggest to override the "bridge" 
> ExecuteCommand class that will do singleton/non-singleton based on an 
> input parameter that could be specified in ActionMapping. 
> Flipping out 
> old ExecuteCommand is a cinch with 1.3 struts-chain.xml
> 
> Or add that as a feature as in a type="[EMAIL PROTECTED]" 
> attribute. Right now I think "instance" should be the default 
> attribute.
>  From the experience that non-thread-save classic Actions are 
> a typical 
> newbie error, which can lead to catastrophic behavior of the 
> application.
> 
> Wolfgang
> 
> 
> Joe Germuska wrote:
> 
> > I've recently been designing applications so that per-action-path 
> > commands are retrieved from Spring rather than from the default 
> > commons-chain CatalogFactory.  This then makes the lifecycle of the 
> > command an external property (based on the "singleton" 
> attribute of a 
> >  element in a Spring beans XML file.)
> >
> > Of course this required custom request processing commands, since 
> > Struts 1.3 doesn't have direct dependencies upon Spring.
> >
> > More to the point, though, I don't think there's really that much 
> > "wow" to saying that Chain can "execute any arbitrary 
> class" -- even 
> > "executing a class" implies that the class implements Command, and 
> > then its not arbitrary any more.
> >
> > The best thing I think would be to write a command which 
> instantiated 
> > this other arbitrary class, extracting properties from the 
> Context to 
> > pass to the "main" method of the arbitrary class 

RE: [OT] Maven dependencies Commercial

[Pilgrim, Peter]

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
====
> 
> You have a couple options.
> 
> Depending on who needs to be to build your project.  If it is just  
> you, then put that jar in your local repository:
> 
> *nix
> ~/.maven/repository/weblogic/jars/
> 

Thanks

Yes of course. It occured to me afterwards this was the way Maven
does its thing  from the "magic" formula

   /s/-.

> Windows
> C:\Documents and Settings\ppilgrim\.maven\repository\weblogic\jars
> 

> If you need other to be able to build it,  you should think about  
> using a remote repository that the people concerned with the project  
> have access to.  You will add multiple locations in your  
> project.properties under the key "maven.repo.remote".
> 
What if you write a project that depends on a requirement of commercial
jar (rar, ear, or zip file)? Ordinarily you could not put a weblogic.jar
on a public maven repository ( but a private, internal repository ).
If there is a copyright jar then I think Maven's easy dependency 
management does not help. In fact it is no better than the original
Ant `build.properties.sample' and customise for your environment.

====
> 
> 
> 
> On Sep 24, 2005, at 5:23 AM, Peter A. Pilgrim wrote:
> 
> >
> > I am getting into Maven using Struts and the OReilly "A Developer  
> > Notebook" edition.
> >
> > One thing I am clueless about is how to tell Maven about a build  
> > that is not
> > in a repository like
> >
> > "weblogic.jar"
> >
> > ?
> >
> > How do tell Maven about ``commercial'' dependencies? Have any of  
> > you guys (and gals)
> > already done this in your professional development lives?
> >
> > 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]
> >
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 



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

[URGENT] Struts 1.1 Source Download

[Pilgrim, Peter]

Can anyone tell me where I can download the full Struts 1.1 source code
other than http://archive.apache.org/dist/struts/ which is being blocked 
by my clients corporate security ?


--
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: [OT] Ant vs. Maven - convince me! :)

[Pilgrim, Peter]

> -Original Message-
> From: Sean Schofield [mailto:[EMAIL PROTECTED]
====
> 
> I do see the dependency advantage but as Craig mentioned, Maven isn't
> the only way to manage this.
> 
> James figured out a nifty way to handle this through a
> "download-dependencies" target in ant.  He showed me how this works in
> Struts and now we're using this approach in MyFaces.  Once I saw this
> technique my enthusiasm for Maven was somewhat diminished I'm pretty
> sure this was not the intended effect as James is a big Maven
> supporter :-)
> 
> Ted mentioned the simplicity of the Strus build.  The MyFaces build
> (using Ant) is just as simple.
> 
> svn co 
> https://svn.apache.org/repos/asf/myfaces/current myfaces-current
> cd myfaces-current/build
> ant dist-all
> 
> That's arguably even simpler than Maven builds because most developers
> already have Ant installed and configured.  Its certainly no more
> complicated.
> 
> I'm not even sure the situation changes when you have lots of
> projects.  If you want to maintain a local repository of jar files you
> can do that in a your home directory or wherever and then just tweak
> the build.properties file to point to that location.
> 

Admittedly I can see the power of multiple versioned repository of JAR
and other dependencies. I thought it was great when I tried with Struts 
SVN yonks back. Of course I used the same thing on another OSS project.
But I remember reading a very crap article about Maven on the ServerSide.com
if was just a turn off man. After the first couple of pages of hope
for future it was rope a dope for the looser. So may Maven has bad
PR off its own back. The writers cant write proper and the advertisers,
just like those who create and sanction television ads, are just simply 
too bonkers.

> I guess that last step I mentioned (the tweaking) is eliminated using
> Maven.  I guess Maven provides a standard way of identifying *local*
> jar files on your machine.  The remote files in the Maven repository
> though, can be used by Ant just as easily.
> 
> sean
> 

The other thing that is, for my own opinion, glaring obvious
is that most IDE have out-of-the-box support for ANT. For instance
Eclipse Ant integration is very good and there is good visual
representation. I suspect the Maven equivalent integrations or
plug-in are rather inferior.

--
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: [OT] Ant vs. Maven - convince me! :)

[Pilgrim, Peter]

My client is currently with a global bank. How could can Maven help
with project dependencies? What are the win-wins here?

When I last looked at Maven, it looked like complete C++/C Macro
nonsense. I did NOT get it all. So what gives?

Does the Struts SVN has a full MAVEN build now? When I played with the SVN
only the disttribution ANT build.xml compiled and built everything 
back in 2004, so what is the state of play now?

> -Original Message-
> From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
====
> 
> 
> Hi all,
> 
> I've seen comments for a while now how Maven is better than 
> Ant... just a
> few minutes ago James posted that Maven is "just smart software".  I
> didn't want to hijack that thread, hence this new one.
> 
> I'm not at all trying to start a flame war here, but I'd like 
> to ask, can
> anyone enumerate some real, legitimate reasons, as far as you are
> concerned at least!, why Maven is better than Ant (or 
> vice-versa if you
> feel that way).
> 
> I'm personally quite comfortable with Ant... it does 
> everything I ask of
> it without feeling like its fighting me... I write all my 
> scripts by hand
> and I don't feel at all like that's a burden, in fact it 
> feels like the
> power is right where it is supposed to be: with me.
> 
> Maven, in my admittedly very limited exposure to it, has 
> seemed confusing
> and rather overwhelming.  Anything of even moderate 
> complexity and power
> feels like that for a while and I recognize that, but I'm 
> trying to decide
> if I truly would gain enough to make the learning curve worth 
> it, and to
> perhaps ultimately try and convince people at work to do so as well.
> 
> What will I actually gain, what benefits will I derive?  I'm 
> looking for
> real, concrete things, things which could, theoretically at least, be
> supported by evidence.  Each person is entitled to their 
> preferences for
> whatever reasons they like, but those don't serve to truly 
> convince anyone
> though :)
> 
> -- 
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
--
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: JDK Version for 1.3.x

[Pilgrim, Peter]

How about Java 5.0?

"Just jokkin' man"

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


> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: 28 April 2005 14:36
> To: Struts Developers List
> Subject: Re: JDK Version for 1.3.x
> 
> 
> 1.4.2 sounds good to me.
> 
> David
> 
> --- Don Brown <[EMAIL PROTECTED]> wrote:
> > I can't find the thread, but 1.4 gets my vote.
> > 
> > Don
> > 
> > Niall Pemberton wrote:
> > > I remember the discussion about the JDK version for 
> Struts 1.3 - but I
> > can't
> > > remember if an actual decision was made. Have we decided 
> on JDK 1.4 as
> > a
> > > minimum for Struts 1.3?
> > > 
> > > 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]
> > 
> > 
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Three more things for 1.4

[Pilgrim, Peter]

> From: Ted Husted [mailto:[EMAIL PROTECTED]
====
> 
> If I went through some of my old applications, I'm sure I could find
> several others. I often passed the action in as a bean and rendered
> via a RTE .

What does RTE stand for?

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

 

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: POJO Actions and the ActionCommand interface (Re: Configurati on inheritance, module init code)

[Pilgrim, Peter]

> From: Konstantin Priblouda [mailto:[EMAIL PROTECTED]
====
> 
> 
> --- "Pilgrim, Peter" <[EMAIL PROTECTED]> wrote:
> > > -Original Message-
> > > From: Konstantin Priblouda
> > [mailto:[EMAIL PROTECTED]
> > > 
> > > 
> > > --- Joe Germuska <[EMAIL PROTECTED]> wrote:
> > > 
> > > > 
> > > > What is your antecedent for "this"?  Having an
> > > > ActionCommand 
> > > > interface?  Using an IoC container as an
> > > > ActionFactory?  Having a 
> > > > ThreadLocal store the current ActionContext?
> > > 
> > > action factory going to IoC container for actions 
> > > exists already. ( Pico/Nanocontainer ) 
> > > 
> > > I even looked at the possibility to obtain tuile
> > > controllers from IoC, but it's  really
> > difficult...
> > > 
> > > regards,
> > > 
> > 
> > What is the use-case of obtaining TilesController
> > from IoC container?
> > 
> > It does not make sense to me. If Struts or other MVC
> > container
> > keeps a record of the TilesController (or Actions,
> > ActionForm etc)
> > then the component can be retrieved from Struts
> > through the API
> > at the correct invocation time.
> 
> 
> It is the same use case as obtaining action from IoC
> container. Advantages are clear - action/controller
> does not need to know:
>  - what IoC we are using
>  - how ( and where ) business logic objects are
> obtained
> 
> 
> A lot of things can be made really simple and easy to
> test if they do not know about MVC framework. And they
> can be reused.
> ( for example menu structures, access counters,
> declarative security... )
> 

I think we are singing from the same hymnsheet, but
obviously different styles. You are talking about
abstracting away dependencies from MVC frameworks.
You have a use-case for wanting to switch at
a moments notice from Struts to Webwork and back
again.

I think I was talking about separating tiers,
as in not involving presentation layer code (e.g
Struts / Shale / JSF whatever ) from your
business layer. 

> > 
> > Usually I think it is the other way around.
> > 
> > Inside your TilesController (or Action, ActionForm)
> > you want
> > to look up a service bean from a IoC assembler.
> 
> This is usually considered antipattern in IoC world. 
> 

My wordings has tied me in knots. The whole point of IoC,
of course, is not to look up dependences and set
them in against object yourself, but to "retrieve" the 
object with the depedencies of that object 
already fixed, available and ready-to-go.

If I understand you correctly, then, you would want
insert intermediate construct between the MVC Framework
and the invocation element (TilesController). In Struts
the only chance to do this is in (Composable) 
Request Processor. So if you want to do this in Struts 1.3
you need to write a `Command' that calls your IoC Assembler.
(In my own IoC framework an assembler is a type of interface 
called `IApplicationAssembler'. In Spring 
`ListableBeanFactory' (?). BTW this term ``assembler'' comes from 
Martin Fowler seminal paper.) 

With the reference IoC Assembler you can retrieve the bean 
from the assembler configuration. You just make sure 
your bean implements the interface you require at the 
time of invocation: TilesController. Bugger, code is a lot 
better for explanations:

public class ExecuteTilesControllerCommand 
implements org.apache.commons.chain.Command 
{
public boolean execute( Context ctx ) {
IApplicationAssembler assembler = getAssemblerFromSomewhere();
String controllerName = retrieveNameFromContext( ctx );
TilesController tilesController = (TilesController)
assembler( "fredsApplication", controllerName );

tilesController.performAction(  );

return false or true;   // Terminate the chain?
}
}

Then configure this Command as part of the Struts 1.3 CRP
and "Bob's your uncle" as they say. Assuming the TilesRequestProcessor
and decompose into similar chain/commands already. Has this work
been done?

> 
> I put a smal demo to show to my pimps - compiled
> deployable .war:
>   http://www.pribluda.de/jobdemo.war
> 

BTW: Do you have this `jobdemo.war' with the source code
available. I can unwinzip the war but all I see are Java classes.
Consider providing a `jobdemo-src.war' with the Java source
code so other people can study it, if you dont mind.

> And sources are donated to picocontainer:
> http://cvs.picocontainer.codehaus.org/vie

RE: POJO Actions and the ActionCommand interface (Re: Configurati on inheritance, module init code)

[Pilgrim, Peter]

See mix-ins!

> -Original Message-
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
===/===

> 
> 
> On Wed, 16 Mar 2005 10:08:15 -0800, Dakota Jack 
> <[EMAIL PROTECTED]> wrote:
> > 
> > On Wed, 16 Mar 2005 09:54:48 -0800, Craig McClanahan 
> <[EMAIL PROTECTED]> wrote:
> > > I agree with Ted, and the reasoning he states.  Indeed, in this
> > > particular respect, Action *should* be inflexible because 
> making it an
> > > interface would encourage you to use it incorrectly.
> > 
> > 
> > How is an interface with the same signature more flexible in any
> > relevant sense here?  I don't see that.  How could an 
> extension of an
> > Action class be more or less encouraging in how you use it 
> "correctly"
> > or "incorrectly" than an implementation of an Action interface?  I
> > don't see what this could mean.
> > 
> 
> One wrong way to use Action (if it were an interface) is:
> 
> public void MyExistingBusinessLogicClass implements Action {
> ... non-Struts-related business methods ...
> public ActionForward execute(...) throws Exception {
> ... call business logic methods in this class ...
> ... return web tier specific navigation value ...
> }
> }
> 
> because it binds your existing business logic to Struts (and therefore
> servlet) APIs when it should be completely independent.
> 

Consider also this anti-pattern

 public void MyExistingBusinessLogicClass 
implements Action, javax.ejb.SessionBean {
 ... non-Struts-related business methods ...
 public ActionForward execute(...) throws Exception {
// try to invoke other methods of this SessionBean
// if you can deploy it successfully
 }
 }

This is a disaster because EJB container is complete different
from the Webapp container in J2EE 1.[34] containers. They
are usually two different classloaders: webapp
container is trying to invoke an EJB container outside
itside its correct environment.


> The corresponding right way:
> 
> public class MyExistingBusinessLogicClass {
> ... non-Struts-related methods ...
> }
> 
> public void MyStrutsAction extends Action {
> public ActionForward execute(...) throws Exception {
> ... acquire reference to MyExistingBusinessLogicClass ...
> ... configure appropriately based on form inputs ...
> ... delegate work to existing business logic methods ...
> ... return appropriate navigation result ...
> }
> }
> 
> The "wrong way" version above is not possible (with Action as a base
> class), due to single inheritance in Java.
> 
> Note that neither approach prevents a different form of "wrong way":
> 
> public void MyExistingBusinessLogicClass extends Action {
> public ActionForward execute(...) throws Exception {
> ... perform business logic directly in this method ...
> ... return web tier specific navigation value ...
> }
> }
> 
> so yes, Action as a class can be misused ... but not in as 
> many different ways.
> 

This is example, which Craig peadogogical provided above, is the
reason that books like "Core J2EE Patterns" and the blueprints
were written to help architects/developer design and build 
functioning applications. BTW: The solution, circa 2004, is to use a
business delegate or use service locator and service to worker
patterns. In 2005 you can replace your business delegate and service
locator with service bean looked up from an  assembler (IoC container).
The container makes your services available to the web application.
The services can be implemented to call EJBs or call OR/M or whatever
you need for business logic. 

> > 
> > > History lesson time.
> > >
> > > Prior to Struts 0.5 (in 2000-2001), ActionForm was indeed an
> > > interface.  It became clear that a large majority of the 
> audience for
> > > Struts was misusing it, by making their VO beans "implement
> > > ActionForm" -- violating the principle that ActionForm 
> was, and is,
> > > part of the View tier (not the Model tier.  It was 
> changed into a base
> > > class precisely to avoid this.
> > >
> > > As you might imagine, this was a controversial decision 
> then.  But I'm
> > > sure glad we did it.
> > 
> > 
> > I also do not see the point in this.  Why cannot you misuse 
> a class to
> > precisely the extent you can misuse an interface?
> 
> Same argument as above, but this time using existing value objects or
> data transfer objects from your model tier, and making them "implement
> ActionForm".  This was happening a *lot* in the early days, and
> changing to a base class fixed at least this misuse scenario.
> 

Craig's solution to restrict the Action and ActionForm to abstract
classes was his best design decision when he developed the Struts
framework. As I alluded to above, many of the principals of the
J2EE platform were not understand by everyone, so I think,

RE: POJO Actions and the ActionCommand interface (Re: Configurati on inheritance, module init code)

[Pilgrim, Peter]

> -Original Message-
> From: Konstantin Priblouda [mailto:[EMAIL PROTECTED]
> 
> 
> --- Joe Germuska <[EMAIL PROTECTED]> wrote:
> 
> > 
> > What is your antecedent for "this"?  Having an
> > ActionCommand 
> > interface?  Using an IoC container as an
> > ActionFactory?  Having a 
> > ThreadLocal store the current ActionContext?
> 
> action factory going to IoC container for actions 
> exists already. ( Pico/Nanocontainer ) 
> 
> I even looked at the possibility to obtain tuile
> controllers from IoC, but it's  really difficult...
> 
> regards,
> 

What is the use-case of obtaining TilesController from IoC container?

It does not make sense to me. If Struts or other MVC container
keeps a record of the TilesController (or Actions, ActionForm etc)
then the component can be retrieved from Struts through the API
at the correct invocation time.

====

Usually I think it is the other way around.

Inside your TilesController (or Action, ActionForm) you want
to look up a service bean from a IoC assembler.

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


==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: POJO Actions and the ActionCommand interface (Re: Configurati on inheritance, module init code)

[Pilgrim, Peter]

> From: Dakota Jack [mailto:[EMAIL PROTECTED]
====
> 
> 
> +42
> 
> 
> On Wed, 16 Mar 2005 09:23:29 +0100, Manfred Wolff
> <[EMAIL PROTECTED]> wrote:
> > Dakota Jack wrote:
> > 
> > >The idea, I thought, was to use the Commands to supplant the
> > >RequestProcessor with a composable request processor.  Some of the
> > >present suggestions are so radical as to provide some 
> question whether
> > >Struts is going to be Struts.  This is especially so of 
> the suggestion
> > >that we tie the ActionForm and the Action together.  Might as well
> > >just go to JSF and Shale?
> > >
> > >
> > I think there is on little design problem in struts that 
> depends on the
> > history: It would be much better, if Action is an interface. So you
> > would have all possibilites to use POJOs, it must only 
> implement the new
> > Action-Interface. Secondly it were also much better, when the
> > execute-Method must only take a context interface. So you have more
> > flexibility and you have no servlet-things at the paramater 
> signature:
> > 
> > public interface Action {
> > void execute(Context context);
> > }

====

This is also very similar to a Commons Chain `Command' 
except that the execute() returns a `boolean' value and
the `Context' is actual a subclass of `java.util.Map';
an interface!

In Expresso Framework, we have tried a similar approach
to abstract away the HttpServlet--ness from our
web handlers.

We have simply controller, which is sort similar to the
`DispatchAction', because it demultiplexes [HTTP] request
to object method by reflection.

public abstract Controller extends org.apache.struts.action.Action {

public  void promptForm( ControllerRequest request,
ControllerRequest response )

public  void processForm( ControllerRequest request,
ControllerRequest response )

...
}

Where our `ControllerRequest' and `ControllerResponse' are 
abstractions. So we can in theory call our `Controllers'
from the command line e.g. outside of the container. 
Commons Chain will give you that flexibility from 
opening the box. All I am saying we are all not far
away from the Chain implementation as it exists now.

In fact there is food for thought, for us Expresso developers
if we want to refactor our `Controllers' as `Commands' in future,
but this off topic ...

It is really a design and backward compatibility issue after all.


> > 
> > where Context is also an interface.
> > 
> > I have programmed this approach by myself
> > 
> (http://plstrutsit.sourceforge.net/architecture/index.html), 
> but it were
> > quite better, if this would be integrated in struts - with backwards
> > compatibility to struts 1.1. You only need a new 
> request-processor that
> > can deal with such Action interfaces an can create such contexts.
> > 
> > Manfred
> > 
> > >If anything, I would tie the ActionForm and the Action 
> less together.
> > >
> > >I don't care what you call an Action.  I do care if it handles the
> > >request and returns an ActionForward.  If you loose that, you loose
> > >Struts altogether in my opinion.
> > >
> > >The whole command structure, remember, is only because you 
> adapted the
> > >Template Method pattern for the parts of the composable request
> > >processor requiring the Command/Chain pattern to fix its 
> difficulties.
> > > To decide for that reason that the Command/Chain structure is some
> > >pattern Valhalla is a serious error, in my opinion.

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

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: POJO Actions and the ActionCommand interface (Re: Configurati on inheritance, module init code)

[Pilgrim, Peter]

> -Original Message-
> From: Niall Pemberton [mailto:[EMAIL PROTECTED]
====
> 
> I've looked at 1.3 and the Chain stuff, but not actually tried it out.
> However the original RequestProcessor is still there and 
> presumably still
> works. The default RequestProcessor is now  the chain
> ComposableRequestProcessor, so to use the original one would 
> have to be
> configured. No one (to my knowledge) has said it should be removed, so
> theres nothing to stop it being maintained/enhanced and if 
> Struts continues
> to ship with both no need (IMO) for a fork. Having said that if
> ComposbaleRequestProcessor does eveything the original one does and is
> backwardly compatible then there probably won't be much motivation to
> continue developing it.
> 
> Niall

I thought original use-case design for the ComposableRequestProcessor
is to solve the multiple inheritance problem with custom request processor.

For example I might mave `ExpressoRequestProcessor' which subclasses
`TilesRequestProcessor', but my framework users are be troubled
if they want to use `WorkflowRequestProcessor', which is not a subclass
of `TilesRequestProcessor'.

In the new world, all the RequestProcessors will be rewritten as
Commands/Chains. It should be simply a case of configurating all
the disparate chains/commands together to invent a new style 
request processor.

I am missing steps sorry. Each RP will rewritten with Commands:

ExpressoRequestProcessor
ExpressoExecuteAction command
ExpressoCreateForm command
...


WorkflowRequestProcessor
WorkflowVerifyUser command
WorkflowPopulateActionForm command
WorkflowProcessAction command
...

TilesRequestProcessor


(NB:The above commands are made-up in my head)
The each RP command will be tied up with the default 
Struts Core Commands (or it may even replace some or all of them!)


The tricky bit is the configuration. Writing your commands must
be fully documented and unit tested for each framework, of course.
Such configuration will be for experts only or must clearly
written up in your application user guide, because potentially
the whole web application could be screwed up ... 
but I suppose that is the fallback of extreme flexibility.

There is also a different use-case, which Ted and other has
discussed, the business logic chain catalogue.

> 
> - Original Message - 
> From: "Dakota Jack" <[EMAIL PROTECTED]>
> Sent: Wednesday, March 16, 2005 5:52 AM
> 
> > I do hope that if Struts v1.3 begins to tie more than the composable
> > request processor to this Command/Chain business that a fork is
> > allowed in Struts v1.2.  Once the problems with the 
> Command/Chain idea
> > begin to cause "hacks" that then enslave the framework to the
> > Command/Chain pattern, things will become frozen rather 
> than fluid, in
> > my opinion.
> >

I do not think so, because clearly you can reconfigure the chain config
for the default ``ComposableRequestProcessor'' to call your
own specialised Commands. Inside your custom Commands you can
break into processing that you want in the Struts processing 
flow. All you have be is an Struts expert on what is exactly
going in the CRP under the surface.

Newbies Struts user will not want to or should be advised 
to "meddle with things you do not [fully] understand" 

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

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Flexible config (was Re: Action threadsafe)

[Pilgrim, Peter]

> -Original Message-
> From: Don Brown [mailto:[EMAIL PROTECTED]
> 
> 
> This reminds me of this improvement Struts was going to make 
> a long time 
> ago, pre 1.1 days for stxx.  stxx wanted to extend the Struts 
> config to 
> add support for multiple xslt transformations.  The problem 
> was Struts 
> config was stuck to a rigid DTD.  A hack was introduced where 
> you could 
> add Digester rules to support your new config elements, but 
> you had to 
> either turn validation off or replace the DTD all together.
> 
> The solution, I believe, is to move to a XML schema-validated Struts 
> config file.  Give the usual Struts config a namespace to validate 
> against.  Then, allow any Struts extension the ability to 
> define their 
> own namespace and have their config intermingle with the 
> normal Struts 
> config.  This allows an extension the ability to add elements and 
> attributes wherever it wants without compromising validation.  It has 
> the added side benefit of making it possible to reduce the 
> size of the 
> element names, since we don't have to make them unique.
> 
> If we did this, and the code detected an old DTD-based 
> config, we just 
> apply an XSL transform and we have 100% backwards compatibility.
> 
====

Namespace of the Struts configuration should be easy as added
a one line to the Digester RuleSetBase class.


--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497


==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: ActionContext chain changes committed

[Pilgrim, Peter]

> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
====
> 
> 
> At 11:58 AM +0100 2/7/05, Wolfgang Gehner wrote:
> >We don't see a case for a switching contexts within the request 
> >cycle to a "ViewContext".
> >
> >- Based on *last weeks* code, we created our own context named 
> >"ActContext" that extends ServletWebContext, so we could add 
> >convenience methods on it that keep our action code clean (like we 
> >want to get the bean in scope by calling "getBean" on the context, 
> >"getIDParameter" to get a request parameter named "ID" we use as 
> >rowId etc etc) With tonight's svn, it could probably extend 
> >ActionContext. To plug it in, we extended 
> >ComposableRequestProcessor. I suspect that extending the default 
> >context will be a pretty standard thing to do, so it might be a good 
> >idea to allow this:
> > >processorClass="org.apache.struts.chain.ComposableRequestProcessor" 
> >contextClass="aaa.bbb.ccc.MyContext"/>
> >Switching contexts within the request cycle would make all this more 
> >difficult.
> >
> >- We also created a DispatchCmd that is modeled after 
> >DispatchAction, so commands that extend it can have methods like 
> >"save(Context context)" when the url is /do/testCmd?method=save
> >
> >The sample app code incl. environment (Eclipse 3.1M4 etc) is there 
> >at http://sourceforge.net/projects/infonoia/
> >I will see that it gets updated tomorrow based on the nightly build 
> >of tonight's svn.
> 
> Based on some of this discussion, I see a few likely good steps:
> 
> * ComposableRequestProcessor should isolate the production of its 
> Context instance into a single method, so that it's easy for a 
> subclass to cause a different implementation class of Context be 
> returned.
> 

+1

> * This method should return ActionContext instead of just 
> o.a.c.chain.Context, so that Struts can "guarantee" that the command 
> which is executed as the "root" of the chain will have one of these, 
> instead of using the wrapping mechanism which is currently used only 
> for the "process-view" subchain.
>

+1
 
> * perhaps there should be a way to simply specify an alternate 
> Context class, instead of requiring a subclass of 
> ComposableRequestProcessor.  However, as I have things set up now, I 
> don't think that's so straightforward.  Context itself has no API 
> about what is to be done with an initial HttpServletRequest or 
> HttpServletResponse; therefore, if one were to specify a Context 
> class, it would really have to be a ServletWebContext or a 
> ServletActionContext.  This isn't something I'm against, but I don't 
> know if it's clear which they should do; until it is, it's not that 
> hard to subclass ComposableRequestProcessor; this saves us the 
> trouble of defining a "ContextFactory" interface which would deal 
> with the setup.
> 

Why open this up with setter / getter property so that IoC container
inside a subclass of the ``ComposableRequestProcessor'' can assemble
it for you?

> In short, this is where I am right now, and what I'll probably commit 
> after waiting a short while for comments.  With this, I would remove 
> the context wrapping from the default chain, and perhaps I'd just get 
> rid of those classes.  (I have a hunch they might sometimes be 
> useful, though, so I might just put them in commons-chain.)
> -
>  public void process(HttpServletRequest request,
>  HttpServletResponse response)
>  throws IOException, ServletException {
> 
>  // Wrap the request in the case of a multipart request
>  request = processMultipart(request);
> 
>  // Create and populate a Context for this request
>  ActionContext context = contextInstance(request, response);
> 
>  // Create and execute the command.
>  try {
>  if (log.isDebugEnabled()) {
>  log.debug("Using processing chain for this request");
>  }
>  command.execute(context);
>  } catch (Exception e) {
>  // Execute the exception processing chain??
>  throw new ServletException(e);
>  }
> 
>  // Release the context.
>  context.release();
>  }
> 
>  protected ActionContext 
> contextInstance(HttpServletRequest request,
>  
> HttpServletResponse response) {
>  // Create and populate a Context for this request
>  ServletWebContext context = new ServletWebContext();
>  context.initialize(getServletContext(), request, response);
>  context.put(Constants.ACTION_SERVLET_KEY,
>  this.servlet);
>  context.put(Constants.MODULE_CONFIG_KEY,
>  this.moduleConfig);
>  return new ServletActionContext(context);;
>  }
> -
> 
> Any feedback is appreciated.
> 



--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston

svn checkout

[Pilgrim, Peter]

Hi

Are they any good online docs on using "svn" with Struts 1.3?
I tried very last night on my linux box:

% svn checkout http://svn.apache.org/repos/asf/struts/trunk  struts

But I must admit I didnt know what I was doing at all.
Do you have to ``svn login'' or whatever?

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497


==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

Removal of Author Tags [was RE: Documentation updates part 2]

[Pilgrim, Peter]

> -Original Message-
> From: Paul Sundling [mailto:[EMAIL PROTECTED]

====

> 
> First off, I see that the documentation equivalent of author tags are
> still being used.  I remember there was the big thing about 
> removing the
> author tags from all java code.  There was even an article on the
> theinquirer.net about it:  http://www.theinquirer.net/?article=14917
> Anyway, let me know if those doc authors should be removed and I'll
> submit a patch.  
> 
> Incidentally, when I submitted a patch to the maven hosted changelog
> plugin last week, I noticed author tags. I also see author 
> tags in this
> project again.  Is it backsliding, or did the policy change?  I could
> also do a patch removing author tags as well.  
> 
> Removing all of these would seem consistent with removing the previous
> contributors page.
> 

Why do you want to remove author tags from the source code base?
Have you totally absolved yourselves from developer attributions?

====

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497


==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Commons Chain Cookbook: Why have Struts Actions?

[Pilgrim, Peter]

> -Original Message-
> From: BaTien Duong [mailto:[EMAIL PROTECTED]
====
> 
> 
> Ted Husted wrote:
> 
> >On Wed, 15 Dec 2004 17:22:15 +, Pilgrim, Peter wrote:
> >  
> >
> >> I was thinking in truth, only providing access to the ``catalog''
> >> and ``command'' not necessarily changing the execution model. But
> >> if that is the case, could a Struts ``Action'' as it appears in
> >> 1.2.6 actually be a commons chain `Command' type? If it is, then,
> >> it opens the doors for the ``chaining action'' conundrum all again.
> >>  
> >>
> >>
> >
> >It's my own feeling that there should be a clean break 
> between the presentation layer (Struts) that collects and 
> display values, and the business logic layer (e.g. Chain) 
> that should do everything else. 
> >
> >I started a new project this week based on Context, Command, 
> and (as of five minutes ago) Spring. The paradigm is that the 
> presentation layer collects whatever values are needed and 
> puts them into a Context. A controller component executes the 
> associated Command (or Chain) and returns the outcome in the 
> Context. Both the Context and Command are extended so that 
> they can handle all the business processing: Input and Output 
> Validation, Execution, Error and Exception Handling, and 
> Message Resolution. 
> >
> >For input, the Context has convenience properties for 
> Locale, User, Role, and for output, there are properties for 
> Output, Errors, Messages, and Fault (Exception). I expect 
> there to be more, but I'm only adding what I need when I need it. 
> >
> >When the Context returns, it can be examined by the 
> presentation layer, which can then display the output, 
> messages, or errors.

When I reread this note, it occurred to me that this is
similar to the way Expresso Controllers are implemented,
except the ``Context'' is split into ``ControllerRequest''
and ``ControllerResponse''. The design was inspired by the 
Java Servlet API specification `ServletRequest', 
`ServletResponse'.

So I'd agree with this `bigger' all-seeing-context design
in principle. I'd factor out some interfaces for Struts
web environment so that people in theory could re-sig
the implementation. 

Can a ``Context'' ever be too big? I mean, everytime a
web user hits a submit then a naive implementation would
create a big context object with a request, response,
errors, etc. What if an naive Struts 1.3+ developer did this
in his or her `FooCommandAction' for every web request

class FooCommandAction {
public Context createKiddieOnContext() {
...

PhotoImage image = new PhotoImage( 2048, 2048 ); // 4Mega Pixel 
grabPhotoFromPersistence( "mallorca0001.jpg", image )
context.put( "myPhoto", image );
...
return context;
}

}

> >
> >  
> >
> This is great Ted. What it means is that each individual backend 
> software component catalog can determine finer grain of authorization 
> and the amount of supplied information. The web layer will 
> take care of 
> the first pass and assemble the supplied fragments. Please 
> let all the 
> mortals know when it is available.
> 

This is C#, so I think he'd have to port it to Java first.

> Thanks
> 
> BaTien
> DBGROUPS
> 
> >It's all in C# now, since I'm working in .NET, but I'd like 
> to port it back to Java 1.5 and maybe PHP 5. 
> >
> >-Ted.
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]


--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Commons Chain Cookbook: Why have Struts Actions?

[Pilgrim, Peter]

> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
====
> 
> Peter:
> 
> If you haven't seen it, this is effectively what the ChainAction 
> does, or at least what it will be doing soon.
>  
>name="LocaleChangeForm"
>  
> type="org.apache.commons.chain.mailreader.struts.CommandAction
> SubclassingChainAction"
>   >
> 
> 
>
>  
>  
> 
> I've got the code written to support arbitrary properties (the new 
> 'key' attribute in set-property), but just ran out of time to write a 
> mini Struts App to demonstrate that it actually works.  The current 
> ChainAction (in struts-chain) only looks for the command in the 
> "default" catalog, because it predates some of the refinement of 
> catalog management in commons-chain.  That limitation was one of the 
> motivations for adding this arbitrary map of properties to 
> ActionConfig.

Yes I also thought of this idea of a map of custom properties.

> 
> I agree that your XML config proposal is nicely concise, but I think 
> we should get some more people using Chain commands in place of 
> actions before making more specific changes to configuration syntax. 

Some period of experimentation, trial and error, discussion is required
before any permanent decision is built into the syntax / API.

> Presumably in the model you describe, Struts would treat the presence 
> of "command" as an alternative form to "type" or "forward" -- that is 
> one of three substantially different execution models.

I was thinking in truth, only providing access to the ``catalog'' and 
``command'' not necessarily changing the execution model. 
But if that is the case, could a Struts ``Action'' as it appears in 1.2.6
actually be a commons chain `Command' type? If it is, then,
it opens the doors for the ``chaining action'' conundrum all again.
 

 
 

Maybe the ``set-property'' attributes can evolve over time.
If it turns out that lots of developers are writing the same
XML code over, then at some point we can migrate it to
proper attributes. We 'd have ease their deployment.

My approach would be beneficial to tool vendors, because it
is easier to parse the XML for `catalog="fooCatalog"' and
`value="fooCommand"' than to analyse the mapping properties
of an ActionConfig.

> It would be possible to skip the action-mapping completely and look 
> up a chain command based on the path, since command names can be any 
> string -- but then we'd have to re-invent all the config which is 
> currently wrapped up in the ActionConfig.
> 

Yes I think that would be possible, removing the ActionMapping 
depedence. I suppose you could also refactor that code into a 
composable request processor / chain implementation. 

I am sure you'ill agree there is going to be more way to slice a 
big cheese in half! It's is going to be, therefore, a lot more 
difficult for tool vendors to say what is the best practice 
for future Struts project. I am worried that there is already 
XML Configuration Hell tidal wave, -- no. strike that --, 
more like flooding in the coast line.

> Joe
> 
> 
> At 10:34 AM + 12/15/04, Pilgrim, Peter wrote:
> >Hello
> >
> >I have read the Commons Chain Cookbook.
> >http://jakarta.apache.org/commons/chain/cookbook.html
> >
> >Regarding the receipe, "Call a Command from Struts", it 
> seems to me that
> >Struts
> >could support the Command more directly in the ActionMapping.
> >
> >Instead of relying on convention, shared database key, or action form
> >name we could expand the ActionMapping schema directly.
> >
> >
> > 
> >  > name="LocaleChangeForm"
> > 
> type="org.apache.commons.chain.mailreader.struts.CommandAction"
> >+
> >+catalog="fooCatalog"
> >+command="fooCommand"
> >+
> > >
> > 
> > 
> > 
> >
> >
> >Obviously the extra attributes are just java.lang.String, and the
> >actual `CommandAction' will have to retrieve them from
> >`ActionConfig' object, and then use them to execute the action.
> >
> >"catalog=fooCatalog" is the name of the catalog in application scope.
> >You could default this attribute to just "catalog" as in the
> >cookbook example or the default value from `ChaingListener'
> >"command=fooCommand" picks a chain from that catalog, wh

Commons Chain Cookbook: Why have Struts Actions?

[Pilgrim, Peter]

Hello

I have read the Commons Chain Cookbook.
http://jakarta.apache.org/commons/chain/cookbook.html

Regarding the receipe, "Call a Command from Struts", it seems to me that
Struts
could support the Command more directly in the ActionMapping.

Instead of relying on convention, shared database key, or action form
name we could expand the ActionMapping schema directly.










Obviously the extra attributes are just java.lang.String, and the 
actual `CommandAction' will have to retrieve them from 
`ActionConfig' object, and then use them to execute the action.

"catalog=fooCatalog" is the name of the catalog in application scope.
You could default this attribute to just "catalog" as in the
cookbook example or the default value from `ChaingListener'
"command=fooCommand" picks a chain from that catalog, which is looked up.

I just pointed that out, because "parameter" may already be used in
the button or javascript controlled method ``DispatchAction''s
derivatives. Also some workshops have a policy document that an
``ActionForm'' must be named `FooBar*Form', and the ``Action''
must be named `FooBar*Action' etc etc

Over to you.

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497


==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Chain enhancement idea

[Pilgrim, Peter]

> -Original Message-
> From: BaTien Duong [mailto:[EMAIL PROTECTED]
== 
> 
> Craig McClanahan wrote:
> 
> >On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska 
> <[EMAIL PROTECTED]> wrote:
> >  
> >
> >>
> >>
> >>>I need to have a hook into processValidate() on validation failure.
> >>>
> >>>Currently that can only be done by copy-and-pasting the 
> processValidate()
> >>>method from RequestProcessor into a subclass and sticking 
> a hook into the
> >>>middle of the code.
> >>>
> >>>When I asked about this on the dev list long ago, it was 
> confirmed that
> >>>there was no other way to do this, but that chain would 
> eventually provide
> >>>this flexibility.
> >>>
> >>>If the chain isn't configured at a fine-grain level, then 
> it's not all that
> >>>much more functional than the existing RequestProcessor.
> >>>  
> >>>
> >>The chain is configured at as fine-grained a level as you like, in
> >>XML.  Hubert is talking about configuring the chain programatically
> >>as well, or at least in some way independent of the configuration of
> >>the primary processing chain.
> >>
> >>
> >>
> >
> >Programmatic configuration is certainly feasible ... there's no
> >requirement in [chain] that you use the XML format at all.  It's just
> >one option.
> >
> >  
> >
> Greetings and request expert advice:
> 
> Commons-chain invented by Craig proves to be very flexible 
> and work in 
> conjuction with other great technonologies. What i am trying 
> to figure 
> out is a proper and practical places for using CoR and IoC (such as 
> Spring framework) in the construction and configuration of software 
> objects. I put out some of my preliminary thinking and hope 
> some experts 
> care to add more arguments to enlighten us.
> 
> 1) Both CoR and IoC (and also Jsf setter injection) enable the 
> configuration and linking objects via XML metadata. But IoC 
> allows the 
> object configuration at a finer level of object attributes 
> and take care 
> of the objects declared as singleton. In this sense, IoC is 
> finer grain 
> than CoR in object creation, configuration and management.
> 
> 2) CoR is very light weight and appropriate for 
> programmatically created 
> processes. It does not not have the complexity and the depth 
> of plug-in 
> features as Spring IoC.
> 

Chain of Responsibility is pattern that separates the sending of a
message from the receiver of message. So it solves 
different problem for inverse of control. I think you are
looking at this from the perspective of `callback interfaces',
therefore IoC appears to have much more power and depth.

> 3) CoR is finer grain than IoC in the construction and rounting of 
> services within and between software layers, while IoC is 
> aprropriate at 
> the application level.
> 

IoC is an application level, because it does help with configuration
and look up of services, beans or other artefacts. 
The CoR is a messaging pattern primarily. It is not a question
of either CoR or IoC, you can use both of them together.

The question is how? That is question of architecture, what is
the best way to build a house, I think you will find a million
and one answers there. There are ways of designing software,
but one needs to understand what the patterns are, what
are they purporting to solve. After that it is easier
to decide if a particular pattern is heavy or lightweight,
better or worse, because each pattern has it original
context of application.

hth

> 4) If we want to combine Jsf as view controller, Spring IoC and 
> commons-chain CoR, a practical infrastructure may be something like 
> followings:
> a) Jsf as a view controller takes care of objects 
> directly related 
> to User Interface (UI)
> b) Spring IoC takes the responsibility of object creation, 
> especially singletons and fine grain configurations of objects not 
> directly related to UI. This is a proper choice of configuration if 
> other features of Spring framework such as application level 
> event and 
> aop are used.

An IoC container can take over construction of objects 
that you required a lightweight container full stop (period).
If you want to take advantage of AOP light weight 
containers then you must register your objects with
the IoC container beforehand.

> c) CoR is used to construct Front Controller a la pattern 
> of Struts 
> of each software module, the rounting of services among modules, and 
> action commands (or chain) of specialized services in each service 
> module. It programmatically links created components from IoC 
> to a finer 
> grain at each software module, which holds the module Catalog 
> of commands.

I think Struts is a FrontController. So I'd be more inclined
to let Struts be Struts. 

There appears to be confusion about CoR and IoC and also
various idioms and patterns common place in the J2EE world.

In the new Struts applications I think there are three chains:
front controller, action, and view. The chain of the front controller
effectiv

RE: Spring dreaming (was Second call: add "generic" mapped proper ty to ActionConfig)

[Pilgrim, Peter]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> 
> 
> On Tue, 30 Nov 2004 11:23:35 +, Pilgrim, Peter wrote:
> >> How is learning and remembering up to 5 different configuration
> >> files  better for the user?  If I was put in this position, I
> >> would seriously  consider other ways of writing Java webapps.
> >>
> >
> > XML configuration cannot replace traditional programming.
> >
> > You can quote me on that.
> >
> > ====
> >
> > XML configuration cannot replace programming
> 
> We're not talking about programming, but configuration. OOP 
> defines a program as a graph of objects. The XML 
> configuration is a convenient way to define the graph of 
> objects we are using to solve the problem. 
> 
> Meanwhile, IoC containers, like Spring, have become the 
> conventional way to create the objects we need at runtime. 
> Some factories can be configured from an XML document, others 
> can be configured by direct calls to the Spring API. Everybody wins :)

This is a misunderstanding between you and I.

External configuration of JavaBeans (or plain old java object) 
with or without XML is the idea of "springing" objects into 
existance without hard wiring of dependencies (http://bridgetown.sf.net)
The IoC/Dependency Injection is the solution to the 
generic service locator problem, which I have been battling
over for a couple of years. So you see, we're not a million
miles apart. 

The warning is that XML configuration of POJO cannot solve all 
problems. There some problems that are really part of the 
programming domain (sequence, iteration, recursion).

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
> 
> 

==
This message is for the sole use of the intended recipient. If you received 
this message in error please delete it and notify us. If this message was 
misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains 
and monitors electronic communications sent through its network. Instructions 
transmitted over this system are not binding on CSFB until they are confirmed 
by us. Message transmission is not guaranteed to be secure.
==


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

RE: Spring dreaming (was Second call: add "generic" mapped proper ty to ActionConfig)

[Pilgrim, Peter]

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
===
> 
> 
> --- Craig McClanahan <[EMAIL PROTECTED]> wrote:
> 
> > I agree with Don's assessment, but wanted to add an FYI 
> note -- Shale
> > does zero-config for #3 (because the mapping between a JSP page and
> > the corresponding ViewController is implicit), and doesn't 
> require #1
> > unless you need it for doing Commons Validator stuff.
> > 
> > Simpler is definitely better.
> 
> But is adding yet another framework to Struts simplifying 
> anything for the
> user or just for us developers?  If we add Spring, we would 
> need to know
> the following to write a Struts webapp:
> 1.  struts-config.xml
> 2.  validator-rules.xml
> 3.  spring.xml (or whatever they call the config file)
> 4.  possibly tiles-config.xml
> 5.  possibly jsf config files
> 
> How is learning and remembering up to 5 different configuration files
> better for the user?  If I was put in this position, I would seriously
> consider other ways of writing Java webapps.

XML configuration cannot replace traditional programming.

You can quote me on that.

====

XML configuration cannot replace programming

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]

[Pilgrim, Peter]

I think I got a book at home in the attic that went into so-called 
``Hot Deployment'' in great detail. (Been a year since I last 
looked at it for generic service locator idea, in the end 
I found myself looking at IoC / Dependency Injections pattern.)

It is addison wesley from 2001-2002. Let me google for you ...

Yep! Here it is 

http://www.amazon.co.uk/exec/obidos/ASIN/0201753065/qid=1101813082/sr=1-5/ref=sr_1_2_5/202-3643115-2068623

# "Component Development for the Java Platform (DevelopMentor Series)"
# by Stuart Halloway
# Paperback 304 pages (January 7, 2002)
# Publisher: Addison Wesley
# ISBN: 0201753065

This is where I got my information from that Hot Deployment is hard to achieve
in Java without careful programming. I think you ask too much for developers
of an application frameworks to follow strict programming rules in
whatever hot deployment scheme you invent. Let's it was so simple
we'd all be doing it.

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497



> -Original Message-
> From: Dakota Jack [mailto:[EMAIL PROTECTED]
> Sent: 29 November 2004 09:00
> To: Struts Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy)
> [was Re: Chain enhancement idea]
> 
> 
> Here is code, as opposed to "pretty pictures" -- LOL  ;-)
> 
> This is intended to demonstrate how simple Had is in contrast to
> normal Service Locator or Inversion of Control (Dependency Injection)
> frameworks.  Remember, THIS IS ALL THE CODE.  There are no
> NanoContainers.  Not XML.  No Config classes, etc.  Where you want to
> have a single class with potential changes in implementations, you
> simply do not change the name of the class, e.g. provide new
> implementations under the same name.  Where you want implementations
> that are different, e.g. if the Action class were an interface, you
> simply use different names for the different implementations and then
> you can hot deploy variations on the code in classes with those names.
>  This allows you to change an existing implementation radically either
> by hot deploy or by name.  Which you want to do depends on the
> situation.  ActionServlet would want to be, for example, an interface
> that allowed differing implementations under "ActionServlet" without
> having different named implemenations, like you have with IoC and
> Service Locator solutions.  On the other hand, you also would get hot
> deploy of various Action implementations under different names, e.g.
> LogonAction, PublishAction, etc.
> 
> A working application with the App interface and client tester is
> available in a zip file, classes.zip, at
> 
> 
> http://131.191.32.112:8080/classes.zip
> 
> 
> This code has some additions that allow us to see whether or not a
> particular object has the last loaded implementation of AppImpl.  The
> code includes:
> 
> App.java
> AppImpl.java
> AppHotFactory.java
> TestAppClientTester.java
> SiteConstant.java
> Classpath.java.java
> 
> To use a new AppImpl, all you have to do is to drop the AppImpl.class
> into the classes/deploy/com/crackwillow/app directory and call
> AppHotFactory.loadAppImpl().
> 
> To see the "name" command work with the client, start the client with
> java com.crackwillow.testing.TestAppClientTester NEW_NAME
> 
> 
> Jack
> 
> 
> 
> 
> 
> -- 
> 
> 
> "You can't wake a person who is pretending to be asleep."
> 
> ~Native Proverb~
> 
> "Each man is good in His sight. It is not necessary for 
> eagles to be crows."
> 
> ~Hunkesni (Sitting Bull), Hunkpapa Sioux~
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea]

[Pilgrim, Peter]

> -Original Message-
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> Sent: 29 November 2004 01:55
> To: Struts Developers List; Dakota Jack
> Subject: Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy)
> [was Re: Chain enhancement idea]
> 
> 
> On Sun, 28 Nov 2004 15:36:27 -0800, Dakota Jack 
> <[EMAIL PROTECTED]> wrote:
> [snip]
> > With hot deploy, instead of switching the implementation 
> and the name
> > of the implementation class, e.g. ColonSeparatedMovieFinder for
> > DatabaseMovieFinder, you just have an implementation called
> > MovieFinderImplementation (or whatever you want, e.g. X) and a
> > MovieFinderImplementationHotFactory for getting object instance
> > implementations of the MovieFinder interfaces.  
> Conceivably, in fact,
> > you can give people differing implementations with the same name by
> > simply putting them in different directories: no problem.  
> This means
> > that the code can be dynamic and alterable at will and that 
> there need
> > be no changes anywhere if you don't want there to be other than
> > dumping the new MovieFinderImplemenation.class in some directory
> > somewhere.
> 
> Within a single JVM (such as a servlet container), the only way to
> have different versions of the same fully qualified class name is to
> use different class loaders, which loads the different versions from
> lots of different places.  That sounds like a pretty significant code
> management issue that any hot deploy strategy like what you describe
> would need to deal with.
> 
> On the other hand, you're going to need individual class loaders to
> solve a different aspect of "hot deploy" as well ... recompiling an
> existing implementation class to modify its behavior (instead of
> trying to switch to a new one).  There is no ClassLoader.unloadClass()
> method in Java, so the only way to "throw away" an old class is to
> throw away the class loader that contained it (and hope that the rest
> of the application doesn't have any pointers to the old class or any
> instances created by it, which would cause a big memory leak).
> 
> That's what a servlet container does, for instance, when you reload an
> app -- it throws away the old context class loader and creates a new
> one.  It's not a perfect solution, but it's not an easy problem,
> either.
> 
> Craig
> 

Late to this thread, but "hot deployment" is quite difficult
to achieve inside a framework without very careful programming
for very reason that Craig explained above. 

First, you need to solve the problem of deciding when the 
use of object is finished (pre garbage collect state) before
you can ever remove the class. Since objects are based on
classes you must know when it safe to discard the object. 

Second, if you need to invent a standard scheme to reload the
class, if some external event (e.g a file modification time
change in your native operating system) occurs.

Third, decide about versioning with your (hot deployable) 
classes. What if I replace the current version of a class B
with an ancient version A? Now if the number of classes of A
is less than the number of classes of B, then you must loop
right back to the first to the first problem.

Hence WebLogic etc have Admin Server and Managed Server to 
handle application and web container requirements, but
it would be harder to further divide this macro architecture 
into more finer architecture and also have good ease-of-development 
& deployment.

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Maven build

[Pilgrim, Peter]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
====
> 
> 
> +1 
> 
====
> 
> Ditto for Subversion. I was stunned by how many Subversion 
> questions there were. It's obvious that a lot of people can 
> use a "compelling replacement for CVS", that is easy to 
> install and plays well with Windows. I think by moving Struts 
> to Subversion, we are leading by example, and may help a lot 
> of teams down a better path. 
> 
> -Ted.

We are thinking of looking at Subversion for Expresso Framework etc, 
so we'ill probably follow your lead. I wonder when / if sourceforge.net
will use it in the near term.

====

> 
> On Sun, 10 Oct 2004 00:10:53 +0100, Marco Tedone wrote:
> > In my company we recently switched to Maven and Struts. Personally
> > I believe Maven is great, not only for the 'xdocs' facility, but
> > from a project management point of view. Its greatest benefit, IMO,
> > is to offer developers a common repository, via the dependency
> > mechanism, promoting integreation of jars versions and component
> > modularization. Amongst its other benefits, I certainly like the
> > fact that Maven promotes versioning stability (through the SNAPSHOT
> > option), it links to CVS repositories creating web reports about
> > developers activities and files checked in/out and the plugin
> > mechanism. If I want to use Ant, as Maven has been defined as an
> > 'Ant wrapper', I simply use ant scripts from within the Maven build
> > files. I believe that offering the possibility of building Struts
> > (and other open source projects) through Maven, will increase also
> > the projects' popularity and contributions. I remember that before
> > Maven, I often given up building from the source because of the
> > dependencies. Today I've downloaded version 1.2.4 of Struts, built
> > through Maven, and except from the build process hanging in the
> > middle a couple of times while downloading jars (I had to restart
> > it a couple of times), the built went on as smoothly as a piece of
> > cake.
> >
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447


==
This message is for the sole use of the intended recipient. If you received this 
message in error please delete it and notify us. If this message was misdirected, CSFB 
does not waive any confidentiality or privilege. CSFB retains and monitors electronic 
communications sent through its network. Instructions transmitted over this system are 
not binding on CSFB until they are confirmed by us. Message transmission is not 
guaranteed to be secure.
==


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

RE: Roadmap

[Pilgrim, Peter]

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> 
> While I don't disagree with any of Ted's points, I do think that we
> need to expand our horizons with Struts Next, rather than just provide
> more of the same. We need to move beyond the traditional web app and
> embrace the next generation of web apps that have some rather
> different characteristics. For example:
> 
> * Many - perhaps even most - requests are not page-replacement
> requests. That is, the response is not a complete HTML page or frame
> to replace the one the request was submitted form.

Partial request would also be true of rich client applications.
The bane of the web app to most business managers is the fact
that "the screen always refreshes". Putting aside the futuristic technology
that renders only sections of the browser screen, I think we should
allow for partial requests and updates. I am unsure how to semantically
describe an interface or design the abstract solution at the mo ...
 
> * The request may not have come from a form or a link; it may have
> been submitted using an XMLHttpRequest object. In such cases, forms as
> we talk about them are not relevant. Instead, we may want to provide
> the request input in the form of a DOM. We may also want to think
> about how to handle input validation in a consistent way across
> different types of requests.

That assumes that everything coming into the Struts Next MVC is a
XML and/or DOM. It may or may not be the case. Sounds like a very
generic request input thing X and output response thing Y going into a 
Struts2 Action as part of the ActionContext though. 
Using adaptors is a known solution.

XML DOM Read Adaptor -> request input thing X
XML DOM Write Adaptor <- respone output thing Y

Anyone could, then, program adaptors for whatever they like e.g flash, 
HTTPServlet{Request,Response}

> 
> * The response may not correspond to a page or a frame. Instead, it
> might be destined for a particular piece of the page (e.g. a div
> element). This allows for partial page updates in interactive
> applications.

Egg-sactly, see above.

> 
> * The response may not be HTML, even when it's headed for the browser.
> It might be XML or even JavaScript code, serialised from a data
> structure, and to be interpreted / evaluated in the browser.
> 
> Not all of these will have a direct impact on the Struts Next core, of
> course. However, I do want to make sure we are thinking about next
> generation apps as we build our next generation framework. ;-)
> 

I think we need to define a feature common denominator table of
what constitutes a request and response as we know they exist now.
Secondly make a first best guess of what future next generation
would look like. Once we have this information we can define what
the interfaces are, or at least make a good guess.

For example, Http environment etc require a URL, action invocation 
path, ServletContext, HttpServletRequest, HttpSession, and yep
HttpServletResponse
objects. 

Then repeat the exercise for portlet jst 169 for that family.

Then anyone else who have written a bleeding edge rich internet application
can also contribute.


> Of course, this is my own itch speaking, since I live in the world of
> highly interactive browser-based applications these days...
> 

One more thing: Could we finally start designing to Java 
interfaces into Struts2? Ta.

interface IActionRequest { ... }
interface IActionResponse { ... }
interface IActionForward { ... }

interface IActionContext {
IActionRequest  getRequest();
IActionResponse getResponse();
}

PS: Got a feeling some of this has been done within Commons Chains when 
I last looked at the jarbundle/.

> --
> Martin Cooper
> 
> 
> On Sun, 10 Oct 2004 15:42:10 -0400, Ted Husted 
> <[EMAIL PROTECTED]> wrote:
> > To follow up some other threads about the "architectural 
> vision" for Struts Next, I'd like to offer the following:
> > 
> > 
> > 
> > Most of us are torn whether to create Struts Next by 
> evolution or revolution. I think what most of us 
> revolutionaries really want to to create Struts Next by 
> mutation. We're not displeased with Struts 1.x. It's just 
> that we are still carrying around an appendix or two that 
> muddle our "clear vision" of the Struts 1.x architecture.
> > 
> > For Struts Next, whether we get there by evolution or 
> mutation, I would envision three pillar components:
> > 
> > * Request Processor
> > * Action/View Context
> > * Form Context
> > 
> > --Request Processor--
> > 
> > The core of the Struts core is now, and has always been, 
> the Request Processor. In Struts 1.0, it was buried amongst 
> other methods in the ActionServlet, but you could see that it 
> was there. In Struts 1.1.x, we pulled it out for all to see. 
> In Struts 1.3.x, we're installing a revolutionary Request 
> Processor based on Commons Chain 
> .
> > 
> > For Struts Next, I'd imagine we'd continue using 

RE: Roadmap

[Pilgrim, Peter]

> -Original Message-
> From: Mike Stanley [mailto:[EMAIL PROTECTED]
> 
> 
> > The other thing I would add is strong debuggability. Is it 
> true that Tapestry's web
> > debugging is the best of the current crop of web 
> application frameworks?
> "Line precise error messages" - are very useful.  This however, is not
> as easy with a JSP engine, given the nature of JSP (template -> source
> -> compile -> class).  Tapestry has the benefit of using it's own html
> template parser.  This provides greater flexibility in terms of
> "knowing" where something goes wrong.
> Struts could improve it's configuration error messages.
> Perhaps someone could write a utility for describing a JspException. 
> Those can be confusing.  lots of nested, stacks.
> But I'm afraid, as long as JSP is the "view", error messages 
> will always
> lack that of Tapestry.  
> - Mike

When JSP is the view then JSP bug fixing and debugging can
be quite difficult. Having your own HTML template parser or
parser technology is the ticket I think.

Struts relies on Jakarta Commons stuff. So I think the pizza base
is only good as the quality of the ingredients on top of it.
Is there a way, for example, to get precise line error when,
say the Digester cant intercept the struts-config.xml file,
or when the underlying SAX XML Parser finds fault.

For error messages to be better, the actual low level module has
to raise comprehensible error messages, because most exceptions
should be rethrown rather than wrapped and logged.

> > 
> > 
> > 
> > > --
> > > 
> > > Personally, I believe the original Struts scenario is 
> sound, which is why it has lasted so
> > > long.
> > > 
> > > (0) Client submits request (1) System receives the 
> incoming request (2) System transfers
> > > matching values to a form object (3) System validates the 
> object (4) System branches to
> > > success or failure. (4a) On success, system 
> executes/delegates the business logic. (4b) On
> > > failure, system returns the faulty input. (5) A view 
> displays the nominal result or
> > > redisplays faulty input.
> > > 
> > > We just need to identify what improvements we need to 
> make at each step, and any additional
> > > steps we'd like to add.
> > > 
> > > It might be interesting to expand this quick list into a 
> formal set of use-case scenarios. If
> > > you have UML Distilled, Fowler mentions scenarios at the 
> opening of Chapter 3.
> > > 
> > > -Ted.
> > > 


--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Re: Struts CVS Dependencies on Commons Libraries e.g Collecti ons 3.1

[Pilgrim, Peter]

> -Original Message-
> From: Craig McClanahan [mailto:[EMAIL PROTECTED]
> 
> 
> On Fri, 27 Aug 2004 12:06:08 -0500, Joe Germuska 
> <[EMAIL PROTECTED]> wrote:
> > At 4:59 PM +0100 8/27/04, Pilgrim, Peter wrote:
> > >Quick fire questions
> > >
> > >What are Struts CVS Dependencies with Commons ?
> > 
> > commons-beanutils: 1.6.1
> > commons-collections: 2.1
> > commons-digester: 1.5
> > commons-fileupload: 1.0
> > commons-lang: 2.0
> > commons-logging: 1.0.4
> > commons-validator: 1.1.3
> 
> I haven't tested the particular combination Peter is talking about
> (Collections 3.1), but in principle it should work fine -- the only
> collections classes that Struts *itself* depends on are compatible.
> 

In my own framework I would like to use Collections 3.1 for 
`OrderedMapCollection' and take advantage of the new `BeanUtilBeans',
`MethodUtilBean' classes etc. It would make my assembly factory 
more flexible and configurable to the developers. 
Is the latest Struts CVS capable of running with these new APIs?

> That being said, you will soon have an additional option (not ready in
> time for Struts 1.2.2 but likely to be for any future version) -- The
> combination of BeanUtils 1.7 and Digester 1.6 will allow you to
> eliminate Collections as a dependency entirely (unless your app needs
> it itself, of course).

Whats are the changes that must be applied to Struts 1.2.x CVS?
 
> Also, as stated elsewhere:
> 
> * Commons Lang is used by the tests; it is not a runtime dependency.
> 
> * Commons Validator has external dependencies of its own on
>   jakarta-oro.jar and antlr.jar
> 
> Craig
> 

Tia

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: Subversion?

[Pilgrim, Peter]

> -Original Message-
> From: Don Brown [mailto:[EMAIL PROTECTED]
> 
> Last I heard, Ted setup a test subversion repository and 
> everyone seemed 
> happy with it.  Is there anything stopping plans to go ahead 
> and migrate 
> our CVS repository?  

Before you kill off the CVS repository ...

====
> Don

... is there a Subversion plug-in or helper available for Eclipse 3 SDK yet?

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

RE: I'm now listed as a PMC member

[Pilgrim, Peter]

> -Original Message-
> From: Alan Mehio [mailto:[EMAIL PROTECTED]
> 
> Congradulation from Alan 
>  
> Best Luck from me 
>  
> Alan Mehio 
> London 
> Niall Pemberton <[EMAIL PROTECTED]> wrote:
> The user guide was updated recently and the "Committer" 
> section has been
> removed and I now appear in the "PMC Member" section.
> http://struts.apache.org/volunteers.html
> I assume this is a mistake ?
> Niall

[ Reading my mail 24+ hours too late as usual ]

Congratulations from me as well.

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

Struts CVS Dependencies on Commons Libraries e.g Collections 3.1

[Pilgrim, Peter]

Quick fire questions

What are Struts CVS Dependencies with Commons ?

Can Struts 1.2.2* work with Common-Collections 3.1?

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447

 

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

Struts version 2.0 and Jericho [was StrutsRelease122]

[Pilgrim, Peter]

I have been skimping tidbits from the "developer patches" thread 
through out this very busy week.

Just out of interest, what is going on Struts 2.0 / Jericho?

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: 27 August 2004 13:30
> To: Struts Developers List
> Subject: Re: [Apache Struts Wiki] Updated: StrutsRelease122
> 
> 
> On Thu, 26 Aug 2004 15:43:50 -0400, James Mitchell wrote:
> > In light of recent bugzilla tickets, should we still go for it?  If
> > so, I'll do it on Sunday.
> 
> If people want to vote -1 they can. It's a majority vote, so 
> a negative vote doesn't poison the well. 
> 
> There are two with patches, which we could apply, but they 
> could also wait for the next release. (We just need to keep 
> these rolling, so a release doesn't become a do-or-die event.) 
> 
> The others look either invalid or rarified to me. In either 
> event, they won't get fixed by not shipping.  We need 
> eyeballs for those. :)
> 
> > I've already began picking though the source and docs updating
> > (locally so far) places that look like they need to reference
> > 1.2.2.  I'll continue with that (time permitting) for now.
> 
> I've been trying to excise any version references, except to 
> say "since x.x.x". Whatever you find should be changed so it 
> doesn't have to be changed again. 
> 
> Ideally, the one place should be the Acquiring page, and all 
> links to the Acquiring page should be to 
 (not the local copy). Then, if they click on 
"Acquriing" offline, they will get the current status. 

-Ted.



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


==
This message is for the sole use of the intended recipient. If you received this 
message in error please delete it and notify us. If this message was misdirected, CSFB 
does not waive any confidentiality or privilege. CSFB retains and monitors electronic 
communications sent through its network. Instructions transmitted over this system are 
not binding on CSFB until they are confirmed by us. Message transmission is not 
guaranteed to be secure.
==


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

FW: [OT] Expresso

[Pilgrim, Peter]

> -Original Message-
> From: Pilgrim, Peter 
> Sent: 10 June 2004 13:00
> To: 'Struts Users Mailing List'; '[EMAIL PROTECTED]'
> Subject: RE: [OT] Expresso
> 
> 
> > From: Pilgrim, Peter [mailto:[EMAIL PROTECTED]
> > 
> > > -Original Message-
> > > From: Andrew Hill [mailto:[EMAIL PROTECTED]
> > 
> > > 
> > > Any Expresso users out there?
> > > Id be interested in hearing your comments and evaluation of 
> > > this framework.
> > > 
> > > It uses Struts as the basis for the presentation layer, Id be 
> > > especially
> > > interested to know if it maintains Struts flexibility of 
> > > allowing you to use
> > > any (i.e.: not JSP) view rendering technology, or will one have 
> > > to depend
> > > heavily on Expresso tags for a lot of things when doing the view?
> > > 
> > Hello Andrew
> > 
> > I am meaning to give a response as an Expresso core committer, but 
> > I am tied up with project requirements meetings all day. I will
> > sent a full reply at home, if you can wait until then.
> > 
> 
> ====
> 
> I have been Expresso developer since December 2000 when I got 
> involved 
> with the framework for electronic MIS project way back for 
> Deutsche Bank in London. I was evaluating various MVC frameworks. 
> At the time Struts was in its infancy (0.5 version). Web Macro and
> Velocity were available, Tapestry, and Barracuda were already
> sharpened tools. I looked at the J2EE compatibility. The number of
> users that supported the product. How many subscribers were on 
> the mailing list? Was it popular? Could get support? 
> How helpful were the developers? I downloaded the source 
> code and had a look at it to see the actual design.
> 
> We choose Expresso because it was more J2EE standards compatible 
> and closer to the Java Servlets and Java Server Pages specs 
> at the time.
> 
> Expresso has a number of features. It had its own MVC 
> framework. It had
> web security. It had HTTP Controllers and most important for Deutsche
> back then it had DBObjects. We are talking 2001 so Hibernate was still
> very young, and JDO did not quite the maturity. DBObjects appealed
> because they were like `Generic Data Transfer Object'. All the 
> data columns could be accessed by using key just like a HashMap.
> Since a lot of the columns were going to be generically and dynamic
> generated using stored procedure engine. Also at the time DBObject
> supported full CRUDS (Create, Retrieve, Update, Delete & Search)
> functionality pretty easily, plus it had nice search and retrieve
> mechanism. Our MIS solution was targeted to a single web application,
> sitting on one Tomcat / Apache Stronghold server, so we 
> didn't require 
> entity EJBs or session beans (J2EE 1.1) and an expensive application 
> server to go with it. 
> 
> I would say the value-add to Expresso was the DBObjects (data objects)
> and the fact we did not have re-invent the wheel creating a
> security matrix, MVC framework, HTTP controllers. Additionally
> Deutsche got other features like Jobs and Long running Queues
> and a couple of useful utilities thrown in for free.
> 
> The picture in 2004 is a little different. Contemporary thinking has
> changed for J2EE developer. 
> 
> (*) We are fast moving to lighter weight framework
> 
> (*) Dependency injection is the "in-thing"
> 
> (*) Build web applications using an abundance of other libraries and
> frameworks is now a reality. We have an environment of 
> ``mix-in technologies''.
>   
>   { Flash / JSP / XML } : 
>   { Struts / Tapestry / Velocity } : 
>   { Castor JDO / Coco Base / Hibernate [ 
> / EJB 3.0 ] )
>   { Pico / Avalon / Spring }
> 
> (*) Other elements of technology that deal with specific problem 
> domains in technology have become stronger and better at what
> they do. e.g. Struts or Hibernate.
> 
> 
> The current Expresso Framework as a "heavy" framework is especially 
> good for building a web application with a load of the heavy duty
> Tonka Toy work is done for you. 
> 
> What are the benefits of Expresso
> 
> Somebody else has built the user login controller and implemented
> a web security matrix. You as a developer don't have to do it.
> 
> Somebody else has built the finite state controller, which is a
> Action subclass and with state method, and you can effectively
> transition between controllers and state (i.e. Action Chain safely)
> You as a developer don't have to write thi

[OT] Struts Users BOF in London in Monday 7th June 2004

[Pilgrim, Peter]

UK Struts Users

We have more people (including myself) who are meeting for informal
drinks on Monday 7th June 2004 19:15 GMT @ Waxy O'Connor (Irish Pub) 
in central London, the West End.

Peter Pilgrim / CSFB
Tim Penhey 
Niall Pemberton
Mike Raath / Bar Cap
Charles Cordingley

If there's anyone else interested please contact me off-list.

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

[ot] testing 1 2 3 4

[Pilgrim, Peter]

testing 1 2 3 4

--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44 (0)207 883 4447

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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

[OT] Test 1 2 3 4

[Pilgrim, Peter]

Test 1 2 3 4

--
Peter P

==
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==


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