trying to upgrade 1.0-->1.1...

[Ri...@LibertyMutual.com]

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:	Kevin.Bedell@sunlife.com [SMTP:Kevin.Bedell@sunlife.com]
> 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" <ni...@cgey.com> on 04/22/2002 10:13:38 AM
> 
> Please respond to "Struts Developers List" <st...@jakarta.apache.org>
> 
> To:   "Struts Users Mailing List" <st...@jakarta.apache.org>
> cc:   "Struts Developers List" <st...@jakarta.apache.org>
> 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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:struts-dev-unsubscribe@jakarta.apache.org
> >
> For additional commands, e-mail:
> <mailto:struts-dev-help@jakarta.apache.org
> >
> 
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------------------
> -
> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>