Additional tests for getting the interceptor bindings from the InvocationContext

[Azquelt]

Follow up to #479 to add a few more tests.

1. Extend InvocationContextTest to include an interceptor binding annotation which is annotated with another interceptor binding.
2. Test applying an interceptor binding to a method using an extension and then retrieving the binding from the InvocationContext.

[Ladicek]

LGTM, though I had to think a little about whether transitive interceptor bindings should appear. They probably should, together with inherited interceptor bindings, but it's likely best to make a small amend to the Interceptors spec: jakartaee/interceptors#106

I also have a change locally that adds a test for getInterceptorBindings() in case of:

• inherited interceptor binding
• method-level interceptor binding "overriding" class-level interceptor binding

I can either add it to this PR, or submit a separate one.

[Azquelt]

I've made the requested changes. I don't mind whether @Ladicek wants to add his tests to this PR or make a new one.

[Ladicek]

I'll submit a 2nd PR once we merge this, then. Probably easiest to review that way.

[manovotn]

LGTM

[Emily-Jiang]

The code changes look good. I have one question regarding copyright. I noticed in most other files, the following copyright text was used:

/*

• JBoss, Home of Professional Open Source
• Copyright , Red Hat, Inc., and individual contributors
• by the @authors tag. See the copyright.txt in the distribution for a
• full listing of individual contributors.
• Licensed under the Apache License, Version 2.0 (the "License");
• you may not use this file except in compliance with the License.
• You may obtain a copy of the License at
• http://www.apache.org/licenses/LICENSE-2.0
• Unless required by applicable law or agreed to in writing, software
• distributed under the License is distributed on an "AS IS" BASIS,
• WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
• See the License for the specific language governing permissions and
• limitations under the License.
  */

In other Jakarta EE projects such as Jakarta Data. The following copyright header is used:

/*

• Copyright (c) 2023 Contributors to the Eclipse Foundation
• This program and the accompanying materials are made available under the
• terms of the Eclipse Public License v. 2.0, which is available at
• http://www.eclipse.org/legal/epl-2.0.
• This Source Code may also be made available under the following Secondary
• Licenses when the conditions for such availability set forth in the
• Eclipse Public License v. 2.0 are satisfied: GNU General Public License,
• version 2 with the GNU Classpath Exception, which is available at
• https://www.gnu.org/software/classpath/license.html.
• SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0
  */

Are there any objections to start using the EF copyright for the new files from now on?

[manovotn]

The code changes look good. I have one question regarding copyright. I noticed in most other files, the following copyright text was used:

These were there historically and as far as I can tell, since the move to Jakarta we haven't been adding them anywhere.

Are there any objections to start using the EF copyright for the new files from now on?

Is there a formal requirement to explicitly add them to all new files? It was my understanding that copyrights on each file are not required. That being said, I'm by no means an expert in this area. It's just my personal take that if we can avoid adding any copyright to files, we should.

[Emily-Jiang]

The code changes look good. I have one question regarding copyright. I noticed in most other files, the following copyright text was used:

These were there historically and as far as I can tell, since the move to Jakarta we haven't been adding them anywhere.

Are there any objections to start using the EF copyright for the new files from now on?

Is there a formal requirement to explicitly add them to all new files? It was my understanding that copyrights on each file are not required. That being said, I'm by no means an expert in this area. It's just my personal take that if we can avoid adding any copyright to files, we should.

@waynebeaton can you confirm?

[Ladicek]

I would very much prefer to deal with license headers in a different issue / PR.

I know that by now, we have many files in the TCK that don't have a license header (because I created them :-) ), so if there's a problem, there needs to be a holistic solution.

[Emily-Jiang]

I would very much prefer to deal with license headers in a different issue / PR.

I know that by now, we have many files in the TCK that don't have a license header (because I created them :-) ), so if there's a problem, there needs to be a holistic solution.

We can merge this PR and deal with the header issue later once we hear from Wayne.

[waynebeaton]

Is there a formal requirement to explicitly add them to all new files? It was my understanding that copyrights on each file are not required. That being said, I'm by no means an expert in this area. It's just my personal take that if we can avoid adding any copyright to files, we should.

@waynebeaton can you confirm?

Please add a copyright and license header on every file when the format permits it.

https://www.eclipse.org/projects/handbook/#ip-copyright-headers

[Emily-Jiang]

Is there a formal requirement to explicitly add them to all new files? It was my understanding that copyrights on each file are not required. That being said, I'm by no means an expert in this area. It's just my personal take that if we can avoid adding any copyright to files, we should.

@waynebeaton can you confirm?

Please add a copyright and license header on every file when the format permits it.

https://www.eclipse.org/projects/handbook/#ip-copyright-headers

Thank you @waynebeaton for the confirmation! I have opened this issue to address your concern.