Re: [rest-dev] @Context removal vs. deprecation

[James Perkins <jperkins@xxxxxxxxxx>]

On Thu, Mar 7, 2024 at 10:36 AM Markus Karg <markus@xxxxxxxxxxxxxxx> wrote:

IIUC then the problem is not the deprecation itself (which is easy) but the missing existance of a replacement?

Correct and I keep leaving this off when I say this :) By deprecation for this, I really mean adding the @Deprecated(forRemoval = true) to the annotations themselves so it's very clear to users this is going to be removed.

 

So shouldn't we concentrate more on building that recplacement *first*?

I'd agree with this. It's something that is about half done in RESTEasy. There are some spec details we need to work out, but as you said that would fall into the "concentrate more on building the replacement first".

 

-Markus

 

 

Von: James Perkins [mailto:jperkins@xxxxxxxxxx]
Gesendet: Donnerstag, 7. März 2024 19:24
An: Jakarta Rest project developer discussions
Cc: Markus Karg
Betreff: Re: [rest-dev] @Context removal vs. deprecation

 

The issue of simply removing it is there is no migration path. That would mean the MicroProfile would not work with Jakarta REST until the MicroProfile API's and implementations can move to the latest Jakarta REST APi. That would likely mean you can't run a MicroProfile deployment in the Jakarta EE $next container if @Context is removed.

 

Having it deprecated first with a replacement, gives the opportunity for other projects to catch up before the removal and have a path forward.

 

On Thu, Mar 7, 2024 at 10:14 AM Markus Karg via rest-dev <rest-dev@xxxxxxxxxxx> wrote:

I think we all should be honest this time. In the past we made plans that apparently nobody could (or wanted to) put into practice.

Do we really have the time to invest all needed resources to finally get rid of JAX-RS's historic non-CDI injection framework?

Or will we end up with the same situation, that we all are +1 for doing so, but few weeks before deadline we all notice that time runs out and we didn't even start?

 

Having that said, I am still +1 for getting rid of @Context, but we should only consent if we really all want to and are willing to invest into it (in particular all vendors, as this feature mostly will stress THEM).

If we do not see that it will happen in time again, we maybe should simply give up that plan and concentrate on smaller things?

 

-Markus

 

 

Von: rest-dev [mailto:rest-dev-bounces@xxxxxxxxxxx] Im Auftrag von Jim Krueger via rest-dev
Gesendet: Mittwoch, 6. März 2024 19:53
An: Jakarta Rest project developer discussions
Cc: Jim Krueger
Betreff: [rest-dev] @Context removal vs. deprecation

 

Hi,

The proposed Jakarta RESTful Web Services 4.0 content (https://deploy-preview-705--jakartaee-specifications.netlify.app/specifications/restful-ws/4.0/) is currently under a “progress review” but is expected to pass within a week.

 

Assuming there are no problems, we can consider the 4.0 content to be set.   And, at least for now, that work will continue in the “main” branch.

 

That brings us to the discussion of what will be next.   Do we push for a version 5.0 that removes @Context injection entirely or a 4.1 version that deprecates @Context injection and provides an alternative implementation?    Both of these options carry many/most of the same concerns and some good progress has been made in the “release-3.2” branch toward deprecation..  

 

So the question is, should this deprecation work continue in a “release-4.1” working branch  or be abandon in favor of a “release-5.0” that removes @Context injection.

 

Personally I prefer deprecation in a 4.1 release prior to removal in a 5.0 release, unless a blocking issue is discovered.  What is your opinion?

 

Thanks

_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

 

--

James R. Perkins

JBoss by Red Hat

--

James R. Perkins

JBoss by Red Hat