Sounds like the problem I was having - see earlier message with subject
"bug in ConfigRuleSet?". Haven't received a response yet.
Regards
Colin M Sharples
I/T Architect
IBM Global Services New Zealand
email: [EMAIL PROTECTED]
phone: 64-4-5769853
mobile: 64-21-402085
fax: 64-4-5765616
Richard.Vaillancourt@Libert
yMutual.com To:
[EMAIL PROTECTED]
cc:
23/04/2002 02:49 Subject: trying to upgrade
1.0-->1.1...
Please respond to "Struts
Developers List"
Greetings-
I have a Struts 1.0 working application, I am having a some issues getting
it running in 1.1.
I have looked around archives, etc. but did not find any upgrade docs
(though appendix D of upcoming Caveness book looks to cover that).
I am receiveing a NullPointerException from the digester trying to parse
the
web.xml, from initApplicationConfig.
Errors out @ line 59, column 23 of ActionMappingFactory.
Thanks in advance for any suggestions.
-Rick
(p.s. - I am trying to get this running in VAJ)
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 10:14 AM
> To: Struts Users Mailing List; Struts Developers List
> Subject: Re: form bean life cycle
>
>
>
>
> Gee -
>
> No sooner did I fire off my response, then I read this response telling
me
> I was all wrong.
>
> <egg-on-face/>
>
> I guess I'm specifying how I design code myself - not how struts does it.
>
> That being said, this limitation of having to specify a concrete class
> only
> should be logged as an "enhancement request" in bugzilla. You should be
> able to either:
>
> 1. Have the form bean subclass an abstract form bean,
> 2. have the form bean implement a form bean interface you define, or
> 3. specify a specific class name.
>
> I'd say also that allowing it to implement an interface is my preferred
> approach over subclassing an abstract class. You can always define an
> Abstract class that implements the interface if you want. That is,
>
> - an interface-based approach allows all of 1, 2, and 3.
> - requiring subclassing allows only 1 and 3.
>
> Sorry for the cross post to the developers list -
>
>
> FWIW -
> Kevin
>
>
>
>
>
> "Nicolas De Loof" <[EMAIL PROTECTED]> on 04/22/2002 10:13:38 AM
>
> Please respond to "Struts Developers List"
<[EMAIL PROTECTED]>
>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> cc: "Struts Developers List" <[EMAIL PROTECTED]>
> Subject: Re: form bean life cycle
>
>
>
> [send in copy on Struts-dev list]
>
> In ActionServlet (Struts 1.0.2) you can read that formBean object found
in
> scope is compared to the form name declared in ActionMapping by testing
> class name, not testing it using an "isInstance" or any other reflection
> mecanism that could allow using inheritance or abstract FormBeans.
>
> instance = (ActionForm) session.getAttribute(attribute);
> ...
> className = formBean.getType();
> ...
> className.equals(instance.getClass().getName())) {
>
>
> Can any Struts developper explain if there is a technical reason to this
> limitation ?
>
>
> > Hello all, I a mwondering about this ?
> >
> > I have a form bean declared abstract and I have subclassed it
> > into three concrete form bean classes that I use, this works OK.
> >
> > Then, I want now, to use an action that does not require to know
> > anything about these concretes implementations: I want my
> > action to work on the interface of the abstract form, for this
> > I have declared an action-mapping to use a form bean
> > of the abstract class and from the session scope, I thought
> > that struts won't try to create the form again (actually it
> > can't because the form class is abstract), infortunatelly
> > the logs of struts told me that struts have tried to create
> > it.
> >
> > My question is why do struts try to recreate the action form
> > if it can be found from the session
> >
> > =============================================================
> > -- KeV --
> > =============================================================
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]
> >
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]
> >
>
>
>
>
>
>
>
>
--------------------------------------------------------------------------
> -
> This e-mail message (including attachments, if any) is intended for the
> use
> of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential and exempt
from
> disclosure. If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited. If you have received this communication in error,
> please notify the sender and erase this e-mail message immediately.
>
--------------------------------------------------------------------------
> -
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
