> -----Original Message-----
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich
>
>
> >>In terms of new functionality, the three biggest fish I'd
> like to fry
> >>are Workflow, SSL, and Unit Testing. Towards that end, I'd like to
> >>consider integrating LivingLogic's Workflow, ssl-ext, and Struts
> >>TestCase into the Struts 2.x development stream. We may
> also want to
> >>consider adding these as standard options to Struts 1.x, so
> >>as to blaze
> >>a trail.
> >
> >
>
> I aqgree that DAO should be outside of Sturts.
> I do not think Workflow should be inside. Becuase I do not
> think it is a
> good practice. It may be needed by some people... as a plug in.
>
Struts greatest strength up to now is its agnostic data model feel.
You need to supply the Model architecture, so I agree there.
It has also been historically a weakness where users have been
a little confused by form bean and data transfer objects.
Ie the various ways of streaming information back and forth
the tier.
>
> > Integrating StrutsTestCase would help with the Unit tests,
> > although it will have to be heavily modified in parallel
> > to keep up with changes in development.
> >
>
> I also do not think testing should be insdide. There are many
> that look
> into JVM, into container's JSP, etc. and people should inovate.
> I use OpenSTA, becuase I want to see what happens under load.
>
Au contraire. I think it would be benefit the framework if there
was a standard Strut's unit test part available out-of-the-box.
It would aid developer's writing containerless unit tests,
otherwise it is down the road with Cactus. Nope. Strike that
.... StrutsTestCase does support Cactus. Whatever the framework
should have unit test of its own delivered whether it is
Struts Test Case or self-amogrified hand crafted
``junit.framework.TestCase'' subclass.
> However... Monitoring and Managing the application while runing in
> production maybe should be included. Ex: Jamon.
> I used it, and it's great.
> I works similar to log4j.
> Or at least it should be documented.
> In days of ClientServer, 3 tier ment:
> Data Layer, Presentation Layer and Managment Layer.
>
You could add this feature on with JMX and MBean and write
a ``ComposableRequestProcessor'' , I mean special Command to
monitor the processor flow. Perhaps you can write an instrumented
`org.apache.commons.chain.Chain implementation' that is JMX
compatible.
> >
> > So you no longer going to pass in request and response objects
> > around, but instead have a context instead. Maybe it would
> > be a little inconvenient for every Action to call
> > ``context.getRequest()'' all the time. Perhaps we can keep them
> > please. I dont mind losing the form bean. I could live with
> > ``context.getForm()'', because for some environments you dont
> > need to buffer a user's input. e.g. web services, or even
> > a flat file.
> >
> > public ActionForward someStateAction(
> > org.apache.commons.chain.Context context,
> > some.generic.request request,
> > some.generic.response response );
> >
> >
>
>
> Why not just KISS and
> public ActionForward someStateAction(
> org.apache.commons.chain.Context context );
>
>
> It can *all* go into context(or a Map!!!), else we have the
> tilesAction
> execute signature.
>
> I can allways do a
> map.get("request")
>
> This would work for SOAP or other protocols.
>
> .V
Yes I agree KISS is better, Vic. It is better by the design.
Maybe you can be person to announce to the Struts 1.0
1.1 user base that all of their Actions are now invalid, they
wont compile for Struts 2.0 because you need to upgrade ALL
your state methods to get HttpServletRequest and
HttpServletResponse and ActionForm and ActionMapping
from the Chains context.
This is early days, and too-low level so I 'd put this point
on the back burner. It can be easily solved using Java Reflection.
--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923
***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office:
36 St Andrew Square, Edinburgh EH2 2YB.
Authorised and regulated by the Financial Services Authority
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The Royal
Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.
Visit our websites at:
http://www.rbs.co.uk/CBFM
http://www.rbsmarkets.com
********************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
