Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes for 1674 #1809

Merged
merged 11 commits into from Dec 5, 2022
Merged

Changes for 1674 #1809

merged 11 commits into from Dec 5, 2022

Conversation

reshmabidikar
Copy link
Contributor

Includes changes for 1674

Following are the related PRs:

Note that until the above PRs are merged, tests will not be green (After merging, the correct version needs to be specified in the killbill/pom.xml).

@reshmabidikar reshmabidikar marked this pull request as ready for review December 1, 2022 13:49
@@ -224,5 +220,23 @@ private InternalTenantContext createInternalTenantContext(final TenantContext te
return internalCallContextFactory.createInternalTenantContextWithoutAccountRecordId(tenantContext);
}

private ValidationErrors validateCatalogInternal(final String catalogXML, final InternalTenantContext internalTenantContext) throws ValidationException, JAXBException, CatalogApiException, TransformerException, SAXException, IOException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of throwing here, could you extract error messages from the exception and add them into the errors?

I'm thinking specifically of errors like:

				Entity: line 2: parser error : Opening and ending tag mismatch: effectiveDate line 2 and effectiveate
				    <effectiveDate>2013-02-08T00:00:00+00:00</effectiveate>
				                                                           ^
				Entity: line 4: parser error : Opening and ending tag mismatch: recurringBillingMode line 4 and recurringBillingMde
				    <recurringBillingMode>IN_ADVANCE</recurringBillingMde>
				                                                          ^
				Entity: line 10: parser error : Opening and ending tag mismatch: category line 10 and catgory
				            <category>BASE</catgory>

or mis-matches in the references (e.g. pricelist with a plan that isn't defined):

Caused by: org.xml.sax.SAXParseException; lineNumber: 52; columnNumber: 11; cvc-id.1: There is no ID/IDREF binding for IDREF 'Standard'.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed as follows:

  • added e.getLinkedException().getMessage() for JAXBException (Since the error message is present in the linkedException)
  • Added throw new IllegalStateException(e) for TransformerException/IOException/SAXException to keep this consistent with the earlier uploadCatalog code

Let me know how this looks.

@sbrossie
Copy link
Member

sbrossie commented Dec 1, 2022

Note that until the above PRs are merged, tests will not be green (After merging, the correct version needs to be specified in the killbill/pom.xml).

@reshmabidikar That should not be the case I think as long as we merge PRs from different repos (killbill, killbill-api, ...) pertaining to the same underlying issue in a consistent way (i.e at the same time) - and I know we have sometimes not respected this and broke things.

So, I would expect: As long as you ensure that your killbill-api and killbill-client-java and killbill repo are all up to date with their respective work-for-release-0.23.x branches, then you should be able to use the snapshots generated from such repos and things should work (code should compile as expected).

@reshmabidikar
Copy link
Contributor Author

So, I would expect: As long as you ensure that your killbill-api and killbill-client-java and killbill repo are all up to date with their respective work-for-release-0.23.x branches, then you should be able to use the snapshots generated from such repos and things should work (code should compile as expected).

My killbill-api repo is in my fork, so this would not result in a snapshot generation isn't it?

@sbrossie
Copy link
Member

sbrossie commented Dec 2, 2022

So, I would expect: As long as you ensure that your killbill-api and killbill-client-java and killbill repo are all up to date with their respective work-for-release-0.23.x branches, then you should be able to use the snapshots generated from such repos and things should work (code should compile as expected).

My killbill-api repo is in my fork, so this would not result in a snapshot generation isn't it?

I see, you are correct. I did not realize there is no snapshot generation until we merge your killbill-api PR. I suppose you can't generate a PR from main killbill-api repo, right - you don't have the rights?

If this is the case, what we could do in the future is create such killbill-api PR against another branch killbill-api:work-for-release-0.23.x-snapshot, and then merge it early to get the snapshot but it complicates the process.

@reshmabidikar I just merged your api PR so you should be able to use 0.54.0-b7e983c-SNAPSHOT

@pierre Are we good from your point of view?

Copy link
Member

@pierre pierre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few things otherwise :shipit:

}
catalogCache.clearCatalog(internalTenantContext);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is required. The validateCatalogInternal method adds the new catalog to be validated to the existing VersionedCatalog in order to perform the validation. This results in the VersionedCatalog in the cache being modified during the validation process without an actual catalog upload being performed. So, the cache needs to be cleared after the validation is complete.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, I missed this. This is risky...

Maybe we should clone the catalog first to be safe (using readExternal/writeExternal). @sbrossie thoughts?

} catch (final ValidationException e) {
errors.addAll(e.getErrors());
} catch (final JAXBException e) {
errors.add(new ValidationError(e.getLinkedException().getMessage(), DefaultVersionedCatalog.class, ""));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe NPE check on e.getLinkedException() just in case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a null check for e.getLinkedException() LMK if this is what you were referring to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see it, maybe the PR was merged too early?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the old PR was merged so I've created a new PR: #1813

@sbrossie sbrossie merged commit c2fb8b2 into killbill:work-for-release-0.23.x Dec 5, 2022
@reshmabidikar
Copy link
Contributor Author

@pierre, I've addressed your review comments and created a new PR: #1813. Please do take another look when you get a chance. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants