> So, this is a long-winded case of asking "why can't we do this"?
The method
public ApplicationConfig ActionConfig.getApplicationConfig()
though this is only used 4 times in struts itself, it is public.
Which means we assume that others extending struts may rely on it.
So to remain recompile friendly we would have to create and return a
ApplicationConfig object. To do this we have to internally contine
to use it a ApplicationConfig object which is just messy.
If we can just ignore this method and delete it then yes the
superclass will be a clean way to go.
In struts 1.0 methods like ActionMappings.getUnknown(), findMapping() are what required
struts to continue to use ActionMappings internally. Is what prevented its removing/deprecation
internally because the superclass method was used. Composition would have allowed the
removal of this class internally.
Composition will allow us to satisy BOTH requirements:
1) deprecate the class,
2) STOP using it internally. To continue to use both internally would cause more confusion.
> Craig
Rob
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
- Re: DO NOT REPLY [Bug 14054] - Rename "Application... Robert Leland
- Re: DO NOT REPLY [Bug 14054] - Rename "Applic... Robert Leland
- Re: DO NOT REPLY [Bug 14054] - Rename "Ap... Ted Husted
