[
https://issues.apache.org/jira/browse/WW-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16160514#comment-16160514
]
Mitth'raw'nuruodo edited comment on WW-4849 at 9/11/17 12:02 AM:
-----------------------------------------------------------------
OK, if this change was really necessary, then:
- It should have been listed in the release notes as a breaking change;
- The documentation for how to write a custom object factory should have been
updated;
- There should have been a transitional period, with the no-arg constructor
present but deprecated, so that third parties could update their code;
- Per [Apache versioning policy|https://apr.apache.org/versioning.html], the
version number should have properly reflected the fact that this was a
non-backwards-compatible change. Since it's not source-compatible with existing
extensions that follow the documentation, this would potentially be a *major*
version number increment. Incrementing only the patch number is very much
against policy:
{quote}
To retain perfect source and binary compatibility, a patch release can only
change function implementations. Changes to the API, to the signatures of
public functions, or to the interpretation of function parameters is not
allowed. Effectively, these releases are pure bug fix releases.
{quote}
Should I assume, then, that the correct way to override {{ObjectFactory}} no
longer requires a default no-arg constructor in the subclass, and submit a pull
request to the Guice project on that basis?
was (Author: thrawnca):
OK, if this change was really necessary, then:
- it should have been listed in the release notes as a breaking change;
- the documentation for how to write a custom object factory should have been
updated;
- there should have been a transitional period, with the no-arg constructor
present but deprecated, so that third parties could update their code;
- per [Apache versioning policy|https://apr.apache.org/versioning.html],
critical security patches should have been released separately, or the version
number should have properly reflected the fact that this was a
non-backwards-compatible change. Since it's not source-compatible with existing
extensions that follow the documentation, this would potentially be a *major*
version number increment.
Should I assume, then, that the correct way to override {{ObjectFactory}} no
longer requires a default no-arg constructor in the subclass, and submit a pull
request to the Guice project on that basis?
> ObjectFactory constructor signature change breaks extensions
> ------------------------------------------------------------
>
> Key: WW-4849
> URL: https://issues.apache.org/jira/browse/WW-4849
> Project: Struts 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.5.13
> Reporter: Mitth'raw'nuruodo
> Fix For: 2.5.14
>
>
> Commit {{6f91d0776a545c911ca4f2875ed9976614711ef9}} changed the signature of
> the {{ObjectFactory}} constructor, breaking all classes that extend
> {{ObjectFactory}} (as per https://struts.apache.org/docs/objectfactory.html).
> This affects eg the [{{guice-servlet}} Struts plugin|
> https://github.com/google/guice/blob/master/extensions/struts2/src/com/google/inject/struts2/Struts2Factory.java].
> This was not listed on the [2.5.13 version
> notes|https://struts.apache.org/docs/version-notes-2513.html] as a breaking
> change, and breaking changes should preferably be avoided in critical
> security updates.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
