On Tue, May 4, 2021 at 12:55 PM Mark Thomas <ma...@apache.org> wrote:
> On 04/05/2021 08:43, Rémy Maucherat wrote: > > On Tue, May 4, 2021 at 9:36 AM Mark Thomas <ma...@apache.org> wrote: > > > >> On 04/05/2021 08:29, Rémy Maucherat wrote: > >>> On Tue, May 4, 2021 at 9:26 AM Mark Thomas <ma...@apache.org> wrote: > >>> > >>>> Hi all, > >>>> > >>>> It is the start of a new month so time to tag and release. I have a > few > >>>> things I'd like to get fixed first: > >>>> > >>>> 1. BZ 65272 (allow CR as HTTP line separator). > >>>> I'm planning on applying PR 417 to address this before I tag > unless > >>>> there are objections. > >>>> > >>>> 2. BZ 65262 (WebSocket & InstanceManager) > >>>> I have a patch for this about 80% complete. I intend to complete > >> and > >>>> apply it before tagging. > >>>> > >>>> Given these (and no more issues raised this week) I'm currently > >>>> expecting the tags to be towards the end of the week. > >>>> > >>> > >>> Can we release a stable Jakarta migration tool before that release ? > >> There > >>> are a couple changes that could be picked up and since it's a > >> subcomponent > >>> it would need to be declared stable anyway. > >> > >> Sure. 0.3.0 or 1.0.0 ? > >> > > > > I think it should move to stable 1.0, unless there's some mandatory > feature > > that got forgotten. > > I can't think of anything. Folks are starting to use it (and Tomcat 10) > and the biggest problem seems to be that users aren't aware of the Java > EE -> Jakarta EE changes. > > Is there merit in attempting to detect an application trying to load a > Java EE 9 class (maybe limit it to Servlet, JSP, EL & WebSocket) and > fail the deployment (assuming we catch the problem early enough) with a > clear error message? Maybe pointing to a (maybe expanded) section in the > migration guide? > That could be a good idea but it goes back to the deployment problem: ideally legacy EE webapps would be detected and migrated automatically (unless configured otherwise). But there is a problem since it's hard to do. Even if the intent is to limit that to classloading, it's only a bit easier. Most webapps do load stuff on startup so that's a great spot to detect this kind of problem, but for the others the error will be lost in the shuffle. Rémy > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
