webwork-devel — WebWork development

Re: Re: [Webwork-devel] Branch or Commit , which?

[matt b. <mat...@ho...>]

For now, I vote to have two modules (core, examples). You could argue 
another module (contrib). But, I think we should wait and see if it still 
makes sense after refactoring into two modules first. I also think we should 
establish a branch/release policy. So, here goes a draft to bat around.

CVS proposal:
- The mainline should be used for current development. Some people prefer to 
only use the mainline for receiving stables bases but this would be 
confusing for people used to checking out the latest code from the mainline. 
So the mainline is the LAG (latest and greatest).
- Branches off the LAG are created for major work and merged back in when it 
is stable. This should be used for major refactoring or other significant 
work. You should tag with root_of_??? where ??? is your change label. The 
branch should be labeled ???_branch. This keeps you from having to hoard 
everything local.
- Other releases ahead of the mainline should be branched. For instance, to 
begin work on 1.1, a branch should be created off the mainline labeled 
dev_1_1. When 1.0 is released, 1.1 branch should be merged into the 
mainline.
- For releases, a tag should be created to snapshot the code. So for 1.0, a 
tag of root_of_1_0 will be created. Any future patches should be worked on a 
branch and appropriate code changes merged into the mainline.

Mechanics of branching and merging:
- Create a tag on the root of the mainline and label it root_of_dev_x_x
- Create a branch on the root of the mainline and label it dev_x_x

-Matt

>
>To: "web...@li..." 
><web...@li...>
>Subject: Re: [Webwork-devel] Branch or Commit , which?
>From: Mike Cannon-Brookes <mi...@at...>
>Date: Tue, 05 Feb 2002 00:45:41 +1100
>
>On 5/2/02 12:24 AM, "Victor Salaman" (vsa...@ho...) penned the
>words:
>
> > Hi Rickard and fellow webworkers:
> >
> > I have a ton of things I would like to commit but have been reluctant to 
>do
> > so since I don't want to add new features before 1.0 as this release has 
>to
> > be extremely stable and throughly tested. And although the stuff I'll be
> > committing has been used in production as of a month ago with no 
>problems
> > whatsoever, I'd like it to be tested by the community before it goes
> > mainstream.
> >
> > Now my question is:
> >
> > 1. Should we make some kind of "sandbox" inside webwork cvs? (for this 
>and
> > future additions)
> > 2. Should we create another module in cvs (for tools relating to 
>webwork).
> > 3. Should I just commit and get it over with (least desired option)?
> >
> > What are your opinions?
>
>I vote #2.
>
>Has any thought been given to splitting up WW slightly post 1.0, with the
>parts that relate to other technologies made into separate modules (ie
>Velocity integration, formproc).
>
>It's quite possible this would enable:
>- modules to have separate release schedules to WW core (which is very slow
>are releasing - but it's OSS so we can't complain ;))
>- the core to be simplified (hopefully?) and dependencies removed
>
>Thoughts?
>
>-mike
>
>
>_______________________________________________
>Webwork-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>------- End of forwarded message -------
>
>


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: [Webwork-devel] Branch or Commit , which?

[Mike Cannon-B. <mi...@at...>]

On 5/2/02 12:24 AM, "Victor Salaman" (vsa...@ho...) penned the
words:

> Hi Rickard and fellow webworkers:
> 
> I have a ton of things I would like to commit but have been reluctant to do
> so since I don't want to add new features before 1.0 as this release has to
> be extremely stable and throughly tested. And although the stuff I'll be
> committing has been used in production as of a month ago with no problems
> whatsoever, I'd like it to be tested by the community before it goes
> mainstream.
> 
> Now my question is:
> 
> 1. Should we make some kind of "sandbox" inside webwork cvs? (for this and
> future additions)
> 2. Should we create another module in cvs (for tools relating to webwork).
> 3. Should I just commit and get it over with (least desired option)?
> 
> What are your opinions?

I vote #2.

Has any thought been given to splitting up WW slightly post 1.0, with the
parts that relate to other technologies made into separate modules (ie
Velocity integration, formproc).

It's quite possible this would enable:
- modules to have separate release schedules to WW core (which is very slow
are releasing - but it's OSS so we can't complain ;))
- the core to be simplified (hopefully?) and dependencies removed

Thoughts?

-mike

[Webwork-devel] Branch or Commit , which?

[Victor S. <vsa...@ho...>]

Hi Rickard and fellow webworkers:

I have a ton of things I would like to commit but have been reluctant to do 
so since I don't want to add new features before 1.0 as this release has to 
be extremely stable and throughly tested. And although the stuff I'll be 
committing has been used in production as of a month ago with no problems 
whatsoever, I'd like it to be tested by the community before it goes 
mainstream.

Now my question is:

1. Should we make some kind of "sandbox" inside webwork cvs? (for this and 
future additions)
2. Should we create another module in cvs (for tools relating to webwork).
3. Should I just commit and get it over with (least desired option)?

What are your opinions?

/V

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

RE: [Webwork-devel] Release - thoughts and issues

[Kjetil P. <kje...@mo...>]

yes..=20

> -----Original Message-----
> From: Rickard [mailto:ri...@mi...]
> Sent: Monday, February 04, 2002 9:02 AM
> To: Kjetil Paulsen
> Cc: web...@li...
> Subject: Re: [Webwork-devel] Release - thoughts and issues
>=20
>=20
> Kjetil Paulsen wrote:
>=20
> > BTW, the server I set up for webwork.org is still available=20
> so if you
> > want to link webwork.sourceforge.net to this an put up some=20
> nice project
> > page, the server issue page, and the builds go ahead...
>=20
>=20
> That's great! Should we simply put the generated docs there?=20
> That would=20
> be easiest I think.
>=20
> /R
>=20
> --=20
> Rickard =D6berg
> Author of "Mastering RMI"
> Chief Architect, TheServerSide.com
>    The Middleware Company - We Build Experts!
>=20

Re: [Webwork-devel] Release - thoughts and issues

[Rickard <ri...@mi...>]

Kjetil Paulsen wrote:

> BTW, the server I set up for webwork.org is still available so if you
> want to link webwork.sourceforge.net to this an put up some nice project
> page, the server issue page, and the builds go ahead...


That's great! Should we simply put the generated docs there? That would 
be easiest I think.

/R

-- 
Rickard Öberg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

RE: [Webwork-devel] Release - thoughts and issues

[Kjetil P. <kje...@mo...>]

>=20
> Alright, and to do this we would only really have to change the build=20
> script, right? I mean, everything is already there, we just=20
> package it=20
> differently. Although, I suppose we need to split index.html=20
> into two,=20
> one for core and one for the examples.

yes, for now we can change the script - later we should make a new
module in CVS for the examples

btw, split the lib directory (like in tss -> lib/core lib/examples)

/kjetilhp

RE: [Webwork-devel] Release - thoughts and issues

[Kjetil P. <kje...@mo...>]

BTW, the server I set up for webwork.org is still available so if you
want to link webwork.sourceforge.net to this an put up some nice project
page, the server issue page, and the builds go ahead...

/kjetilhp

> -----Original Message-----
> From: Rickard [mailto:ri...@mi...]
> Sent: Monday, February 04, 2002 8:36 AM
> To: Kjetil Paulsen
> Cc: web...@li...
> Subject: Re: [Webwork-devel] Release - thoughts and issues
>=20
>=20
> Kjetil Paulsen wrote:
>=20
> > I'm really looking forward to the release of webwork but I=20
> do have some
> > second thoughts on all the deployment errors showing up=20
> from different
> > servers - I know most of them are probably server bugs, but I don't
> > think most developers will see this, and will not be happy with the
> > release if it doesn't deploy nicely to their current=20
> development server.
>=20
>=20
> I agree, this is very annoying, and no it would be hard to see what's=20
> the real cause of these errors if all you do is deploy webwork.ear.
>=20
>=20
> > We separate the actual framework and the examples - this=20
> because most of
> > the 'bugs' are related to the 3rd party libs that are used - many
> > containers are not happy with libs that are being deployed=20
> which already
> > exists in the container, and since the 'core' probably will=20
> deploy on
> > most containers, people can live with the fact that all=20
> examples doesn't
> > work on their container - at least if we try make a list stating the
> > issues with the most common servers.=20
>=20
> What would this mean, concretely? I mean, webwork.jar is=20
> already created=20
> as a separate jar file. Do you want two deployable .ear files? What=20
> would the "core" one include?
>=20
> /Rickard
>=20
> --=20
> Rickard =D6berg
> Author of "Mastering RMI"
> Chief Architect, TheServerSide.com
>    The Middleware Company - We Build Experts!
>=20

Re: [Webwork-devel] Release - thoughts and issues

[Rickard <ri...@mi...>]

Kjetil Paulsen wrote:

>>What would this mean, concretely? I mean, webwork.jar is 
>>already created 
>>as a separate jar file. Do you want two deployable .ear files? What 
>>would the "core" one include?
>>
> 
> We distribute one war file and one ear file.
> 
> Core -> webwork.jar and the docs in a .war file togheter with the test
> jsp that tests the core funcionality - like it was at the beginning -
> and a page that tells you how to deploy the .ear, and that you can run
> into issues with some containers because of the libs (and maybe a link
> to some page somewhere that have an updated list of 'server issues')
> 
> Full -> Core + examples

Alright, and to do this we would only really have to change the build 
script, right? I mean, everything is already there, we just package it 
differently. Although, I suppose we need to split index.html into two, 
one for core and one for the examples.

/Rickard

-- 
Rickard Öberg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

RE: [Webwork-devel] Release - thoughts and issues

[Kjetil P. <kje...@mo...>]

> What would this mean, concretely? I mean, webwork.jar is=20
> already created=20
> as a separate jar file. Do you want two deployable .ear files? What=20
> would the "core" one include?

We distribute one war file and one ear file.

Core -> webwork.jar and the docs in a .war file togheter with the test
jsp that tests the core funcionality - like it was at the beginning -
and a page that tells you how to deploy the .ear, and that you can run
into issues with some containers because of the libs (and maybe a link
to some page somewhere that have an updated list of 'server issues')

Full -> Core + examples

/kjetilhp

Re: [Webwork-devel] Release - thoughts and issues

[Rickard <ri...@mi...>]

Kjetil Paulsen wrote:

> I'm really looking forward to the release of webwork but I do have some
> second thoughts on all the deployment errors showing up from different
> servers - I know most of them are probably server bugs, but I don't
> think most developers will see this, and will not be happy with the
> release if it doesn't deploy nicely to their current development server.


I agree, this is very annoying, and no it would be hard to see what's 
the real cause of these errors if all you do is deploy webwork.ear.


> We separate the actual framework and the examples - this because most of
> the 'bugs' are related to the 3rd party libs that are used - many
> containers are not happy with libs that are being deployed which already
> exists in the container, and since the 'core' probably will deploy on
> most containers, people can live with the fact that all examples doesn't
> work on their container - at least if we try make a list stating the
> issues with the most common servers. 

What would this mean, concretely? I mean, webwork.jar is already created 
as a separate jar file. Do you want two deployable .ear files? What 
would the "core" one include?

/Rickard

-- 
Rickard Öberg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

[Webwork-devel] Release - thoughts and issues

[Kjetil P. <kje...@mo...>]

Hi

I'm really looking forward to the release of webwork but I do have some
second thoughts on all the deployment errors showing up from different
servers - I know most of them are probably server bugs, but I don't
think most developers will see this, and will not be happy with the
release if it doesn't deploy nicely to their current development server.
It would be very time consuming to test all the servers out there and
try to eliminate the problems in one way or the other, so here is my
suggestion:

We separate the actual framework and the examples - this because most of
the 'bugs' are related to the 3rd party libs that are used - many
containers are not happy with libs that are being deployed which already
exists in the container, and since the 'core' probably will deploy on
most containers, people can live with the fact that all examples doesn't
work on their container - at least if we try make a list stating the
issues with the most common servers.=20

Thoughts ?

/kjetilhp

......mogul.technology..............................................
 mogul technology as > kjetil h.paulsen - senior software architect
 drammensveien 134, NO-0277 oslo, norway
 cell +47 93060327, tel +4724114300, fax +4724114399
 kje...@mo..., http://www.mogul.com
 PGP fingerprint: DA54 A106 1989 FEF0 294F  63A4 9FC6 0F8E 21AD 0180
 ICQ -> 66288365
..............................................mogul.technology......

Re: [Webwork-devel] Release date

[Maurice P. <Ma...@Vi...>]

Fixed.


On Thursday, January 31, 2002, at 09:41  AM, Hiram Chirino wrote:

> Hi Rickard,
>
> I would be nice if the following bug/patch:=20
> =
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D510047&group_=
id=3D
> 14797&atid=3D114797
>
> were fixed.
>
> Regards,
> Hiram
>
>
>> From: Rickard <ri...@mi...>
>> To: web...@li...
>> Subject: [Webwork-devel] Release date
>> Date: Thu, 31 Jan 2002 10:16:33 +0100
>>
>> Hi!
>>
>> Since the docs are looking better now, I suggest that we aim for a
>> release date of Feb 15. By then we should have gotten the remaining
>> parts of the docs in.
>>
>> If you feel that there are any minor outstanding issues with WebWork
>> left, now would be a good time to discuss them. For major changes we
>> should wait until after the release.
>>
>> regards,
>>   Rickard
>>
>> --
>> Rickard =F7berg
>> Author of "Mastering RMI"
>> Chief Architect, TheServerSide.com
>>   The Middleware Company - We Build Experts!
>>
>>
>> _______________________________________________
>> Webwork-devel mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at=20
> http://explorer.msn.com/intl.asp.
>
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>

[Webwork-devel] CVS update: 'webwork/src/main/webwork/util Query.java'

[Maurice C. P. <mau...@us...>]

Update of /cvsroot/webwork/webwork/src/main/webwork/util
In directory usw-pr-cvs1:/tmp/cvs-serv2108

Modified Files:
	Query.java 
Log Message:
fixed very small oops in expression limit patch

[Webwork-devel] CVS update: 'webwork/src/main/webwork/util Query.java'

[Maurice C. P. <mau...@us...>]

Update of /cvsroot/webwork/webwork/src/main/webwork/util
In directory usw-pr-cvs1:/tmp/cvs-serv1584

Modified Files:
	Query.java 
Log Message:
removed 10 element limit of expressions

Re: [Webwork-devel] Release date

[Matt B. <ma...@sm...>]

How about a roll call. If you are working on some documentation and are not
finished, please respond so we can figure out what is left to be written.

Thanks.

I will go ahead and take the Error Handling section.

-Matt

----- Original Message -----
From: "Rickard" <ri...@mi...>
To: <web...@li...>
Sent: Thursday, January 31, 2002 3:16 AM
Subject: [Webwork-devel] Release date


> Hi!
>
> Since the docs are looking better now, I suggest that we aim for a
> release date of Feb 15. By then we should have gotten the remaining
> parts of the docs in.
>
> If you feel that there are any minor outstanding issues with WebWork
> left, now would be a good time to discuss them. For major changes we
> should wait until after the release.
>
> regards,
>    Rickard
>
> --
> Rickard Öberg
> Author of "Mastering RMI"
> Chief Architect, TheServerSide.com
>    The Middleware Company - We Build Experts!
>
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel
>
>

Re: [Webwork-devel] Release date

[Hiram C. <coj...@ho...>]

Hi Rickard,

I would be nice if the following bug/patch: 
http://sourceforge.net/tracker/index.php?func=detail&aid=510047&group_id=14797&atid=114797

were fixed.

Regards,
Hiram


>From: Rickard <ri...@mi...>
>To: web...@li...
>Subject: [Webwork-devel] Release date
>Date: Thu, 31 Jan 2002 10:16:33 +0100
>
>Hi!
>
>Since the docs are looking better now, I suggest that we aim for a
>release date of Feb 15. By then we should have gotten the remaining
>parts of the docs in.
>
>If you feel that there are any minor outstanding issues with WebWork
>left, now would be a good time to discuss them. For major changes we
>should wait until after the release.
>
>regards,
>   Rickard
>
>--
>Rickard Öberg
>Author of "Mastering RMI"
>Chief Architect, TheServerSide.com
>   The Middleware Company - We Build Experts!
>
>
>_______________________________________________
>Webwork-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webwork-devel



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

[Webwork-devel] Release date

[Rickard <ri...@mi...>]

Hi!

Since the docs are looking better now, I suggest that we aim for a 
release date of Feb 15. By then we should have gotten the remaining 
parts of the docs in.

If you feel that there are any minor outstanding issues with WebWork 
left, now would be a good time to discuss them. For major changes we 
should wait until after the release.

regards,
   Rickard

-- 
Rickard Öberg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

RE: [Webwork-devel] Status

[<fbe...@py...>]

Thanks for the reply

I already got the version out of cvs

Is there someone currently working on documentation? Wich sections?
Once I know that, I may pick a section I feel cumfortable with.

Regards
______________________________________________
François Beauregard
Pyxis Technologies
Vice-président, recherche et développement

Tel: (450) 681-9094
Fax: (450) 681-5758
fbe...@py... <mailto:fbe...@py...>



-----Original Message-----
From: in...@sm... [mailto:in...@sm...]
Sent: January 28, 2002 11:32 AM
To: fbe...@py...
Cc: web...@li...
Subject: Re: [Webwork-devel] Status


RC3 is a little old. I would recommend getting the latest from CVS. The only
thing outstanding is finishing up documentation. You are welcome to
contribute in that area.

-Matt

>I had a look at webwork and it seems great. What is
>the status for the release (it seems currently in RC3)?

[Webwork-devel] Status

[<fbe...@py...>]

I had a look at webwork and it seems great.

What is the status for the release (it seems currently in RC3)?
Is there some work going on right now?
Is there somewhere I can contribute?

Cheers
______________________________________________
François Beauregard
Pyxis Technologies
Vice-président, recherche et développement

Tel: (450) 681-9094
Fax: (450) 681-5758
fbe...@py...

[Webwork-devel] CVS update: 'webwork/src/main/webwork/util ValueStack.java'

[Victor S. <sa...@us...>]

Update of /cvsroot/webwork/webwork/src/main/webwork/util
In directory usw-pr-cvs1:/tmp/cvs-serv26142

Modified Files:
	ValueStack.java 
Log Message:
Added methods to check if the stack is empty and to check the size.

Re: [Webwork-devel] ResultException in prepare()

[Rickard <ri...@mi...>]

Jim...@do... wrote:

> I would like it in prepare because we often instantiate an object in 
> prepare. Then, the subsequent setXXX methods can have an object to go 
> against, as opposed to storing the setXXX values in intermediate dummy 
> strings and such.


Yup, that was the idea.


> Now, if there is an error instantiating this object in prepare(), such as 
> a finder exception, I would like to addError() and get the heck out with a 
> ResultException(INPUT). Without this, I have to wait until doExecute() to 
> bail, which means I have to wrap all of my setters with a "if (object != 
> null)" methods.


Your "setters"? These are called by WW, and not your own code. Adding an 
error is indeed a good way to trap it.


> It seems much cleaner to extend the try block to include the getAction() 
> call.


How would you propose then that action delegating work, i.e. where an 
action uses ActionFactory.getAction() to do delegation? How would code 
doing that look like?


> As to extending RuntimeException, I ran into a situation where I was 
> extending ResultException, and it was more convenient for me to have it as 
> a RuntimeException. 


Why? Can you give example code?

> I didn't see any design issues, especially since you 
> are expecting it to be only called in execute(). I can think of situations 
> when I would prefer it to be called in prepare(). (Full circle, no?) ;-)


See above, result selection should only be done in execute(), but it's 
ok to let errors from prepare() influence that selection. But the 
selection itself should not be done in prepare() I think, or we would 
have to revise the entire action lifecycle pretty heavily.

/Rickard

-- 
Rickard Öberg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

[Webwork-devel] CVS update: 'webwork/src/main/webwork/dispatcher ServletDispatcher.java'

[Victor S. <sa...@us...>]

Update of /cvsroot/webwork/webwork/src/main/webwork/dispatcher
In directory usw-pr-cvs1:/tmp/cvs-serv25308/webwork/dispatcher

Modified Files:
	ServletDispatcher.java 
Log Message:
Made the stack's head value be stored in the request's attribute map upon it
being popped from the stack. This is to ease in integration of other programs
which might want to interact with Webwork's action after it's done processing.

APPLICABILITY: This will allow sitemesh's filter to push this value back in the stack 
before decorating,and popping it when done, therefore giving the decorator 
access to anything that was available from the decorated page.

[Webwork-devel] FW: JSR 167: Java Portlet Specification

[Mike Cannon-B. <mi...@at...>]

For those interested - this caused me much amusement, good to see there's
only one portlet API now ;)

-mike

------ Forwarded Message
From: Harold Ogle <har...@SU...>
Reply-To: "Java Community Process (JCP) general information/announcement
list" <JCP...@JA...>
Date: Tue, 22 Jan 2002 16:39:35 -0800
To: JCP...@JA...
Subject: JSR 167: Java Portlet Specification

The submitter of the following JSR:

    JSR-000167 Java Portlet Specification

has withdrawn it from consideration.

"As there is very significant overlap between JSRs 162 & 167, Sun and IBM
have
reached a mutual agreement regarding the proposals. We have now reached a
point
where we feel that we have a mutually acceptable new combined JSR proposal,
which we now wish to seek endorsement of from the existing supporters of JSR
162
and 167."

===========================================================================
To unsubscribe, send email to lis...@ja... and include in the body
of the message "signoff JCP-INTEREST".  For general help, send email to
lis...@ja... and include in the body of the message "help".

------ End of Forwarded Message

Re: [Webwork-devel] ResultException in prepare()

[<Jim...@do...>]

I would like it in prepare because we often instantiate an object in=20
prepare. Then, the subsequent setXXX methods can have an object to go=20
against, as opposed to storing the setXXX values in intermediate dummy=20
strings and such.

Now, if there is an error instantiating this object in prepare(), such as=20
a finder exception, I would like to addError() and get the heck out with a =

ResultException(INPUT). Without this, I have to wait until doExecute() to=20
bail, which means I have to wrap all of my setters with a "if (object !=3D =

null)" methods.

It seems much cleaner to extend the try block to include the getAction()=20
call.

As to extending RuntimeException, I ran into a situation where I was=20
extending ResultException, and it was more convenient for me to have it as =

a RuntimeException. I didn't see any design issues, especially since you=20
are expecting it to be only called in execute(). I can think of situations =

when I would prefer it to be called in prepare(). (Full circle, no?) ;-)

-jim





Rickard <ri...@mi...>
01/22/2002 06:40 PM

=20
        To:     Jim...@do...
        cc:     web...@li...
        Subject:        Re: [Webwork-devel] ResultException in prepare()


Jim...@do... wrote:

> It would be handy to be able to throw a ResultException from prepare(),=20
> especially in our Update actions. Any hope of extending the try block in =


> ServletDispatcher around the ActionFactory.getAction(actionName) method?


Well, no, not really. ResultException is just a fancier way of selecting=20
the return value from execute(), and prepare() is not done as a part of=20
that process, but rather as a part of the instantiation.

Why do you want it?


> Also, I would suggest that ResultException extend RuntimeException.=20

Well.. it doesn't make much difference for execute() since it throws=20
Exception.

/Rickard

--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!

Re: [Webwork-devel] ResultException in prepare()

[Rickard <ri...@mi...>]

Jim...@do... wrote:

> It would be handy to be able to throw a ResultException from prepare(), 
> especially in our Update actions. Any hope of extending the try block in 
> ServletDispatcher around the ActionFactory.getAction(actionName) method?


Well, no, not really. ResultException is just a fancier way of selecting 
the return value from execute(), and prepare() is not done as a part of 
that process, but rather as a part of the instantiation.

Why do you want it?


> Also, I would suggest that ResultException extend RuntimeException. 

Well.. it doesn't make much difference for execute() since it throws 
Exception.

/Rickard

-- 
Rickard Öberg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
   The Middleware Company - We Build Experts!