[
https://issues.apache.org/jira/browse/GEODE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138688#comment-17138688
]
ASF GitHub Bot commented on GEODE-8251:
---------------------------------------
albertogpz commented on pull request #5257:
URL: https://github.com/apache/geode/pull/5257#issuecomment-645524694
> > > > What's the point for these changes?
> > > > I have ran the test case without them and it passes.
> > > > Also, I have searched in the Geode code for the use of this file and
have only found it in `ObjectInputStreamFilterWrapper.java`. From what I see
there, only the first part of every line, the class name, is used.
> > > > What am I missing?
> > >
> > >
> > > the previous version of Deployment has variable name "jarFileName"
instead of "fileName", when we are deserializing a previous version bytes, if
the variable name doesn't match, it won't take the value. We should have a test
to verify that, but I saw the behavior in the debugger.
> >
> >
> > I understand that. What I do not get are the changes in the
> > > > What's the point for these changes?
> > > > I have ran the test case without them and it passes.
> > > > Also, I have searched in the Geode code for the use of this file and
have only found it in `ObjectInputStreamFilterWrapper.java`. From what I see
there, only the first part of every line, the class name, is used.
> > > > What am I missing?
> > >
> > >
> > > the previous version of Deployment has variable name "jarFileName"
instead of "fileName", when we are deserializing a previous version bytes, if
the variable name doesn't match, it won't take the value. We should have a test
to verify that, but I saw the behavior in the debugger.
> >
> >
> > I understand the change in the members of the class. What I do not get
is why it needs to be reflected in
sanctioned-geode-management-serializables.txt.
> > Who is accessing that file?
>
> the `AnalyzeManagementSerializablesJUnitTest` is making sure that we don't
make random changes in those serialized classes. Every change in the sanction
list poses a potential upgrade issue. So the fact that the test is broken will
make the developer think twice about the changes he/she is making to the class.
I see now. Thanks for the clarification.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> exception creating domain.Configuration stops locator startup after rolling
> upgrade
> -----------------------------------------------------------------------------------
>
> Key: GEODE-8251
> URL: https://issues.apache.org/jira/browse/GEODE-8251
> Project: Geode
> Issue Type: Bug
> Components: configuration
> Affects Versions: 1.13.0
> Reporter: Bill Burcham
> Assignee: Jinmei Liao
> Priority: Major
> Labels: GeodeOperationAPI
>
> As reported on the dev@geode mailing list
> https://markmail.org/message/qfnnj2s2x7dzbnzx and shown in the
> {{testRollingUpgradeOfGeodeWithGfs}} test in PR:
> https://github.com/apache/geode/pull/5224, if custom Jars are deployed, the
> locator doesn't start after a rolling upgrade and we see:
> {code}
> org.apache.geode.SerializationException: Could not
> create an instance of
> org.apache.geode.management.internal.configuration.domain.Configuration
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
