Rob,

Thanks, I did see the evolution of the code from PlugInPatch. 
The way the code sits now, you have to update. By deprecating 
init(..ApplicationConfig) and adding init(...ModuleConfig) you would 
only have to update if a deprecated warning is unacceptable. For 
my code, I just updated the offending plugin to use ModuleConfig, 
but I didn't write the plugin (Struts Menu) and don't know the schedule

for the next update. That seems pretty heavy handed.

You are right about the 5 minutes to fix -- once you identify the 
problem assuming you have the source. It is difficult to identify 
the problem if you are working with someone else's jar file because 
all you get is an AbstractMethodError. If you have the source 
and see a deprecated message it also points you to the solution 
where a method not found error will not be as obvious.

Thanks,

David Morris

>>> [EMAIL PROTECTED] 01/06/03 01:50PM >>>
David Morris wrote:
> One problem I had with Beta 3 is related to a change to the PlugIn 
>
(http://cvs.apache.org/viewcvs/jakarta-struts/src/share/org/apache/struts/action/PlugIn.java.diff?r1=text&tr1=1.6&r2=text&tr2=1.7&diff_format=l)
> 
> that forces an update to any class that implements Plugin. Looking 
> at the ActionServlet class it appears that a lot of work went into 
> making ModuleConfig implementation backward compatible with 
> ApplicationConfig. It looks like PlugIn initialization could also be

> backward compatible. Was this an oversight or by design? 

By evolution.


Until Dec 18th or so, there was another class named PlugInPatch
which implemented the new method. It allowed Plugin developers
to use their original plugin with no modifications. However,
this method caused a 'deprecated' warning message. The issue was
raised that some QA people will not allow any code that uses
deprecated
methods to go into production. The general feeling from the comitters
was that PlugIn developers would be an advanced user and could be 
expected to take the 5 minutes or less to update & recompile
their Plugin with the new Method signature.
The result was that the PlugInPatch Interface was removed
and the new init() method moved into the PlugIn class, removing the 
original init().

-Rob

> 
> David Morris


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to