Hi Rémy, On Fri, Mar 13, 2020 at 12:27 PM Rémy Maucherat <r...@apache.org> wrote:
> On Fri, Mar 13, 2020 at 11:00 AM Martin Grigorov <mgrigo...@apache.org> > wrote: > >> Hi Rémy, >> >> On Thu, Mar 12, 2020 at 6:58 PM Rémy Maucherat <r...@apache.org> wrote: >> >>> On Thu, Mar 12, 2020 at 3:10 PM <mgrigo...@apache.org> wrote: >>> >>>> This is an automated email from the ASF dual-hosted git repository. >>>> >>>> mgrigorov pushed a commit to branch master >>>> in repository >>>> https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git >>>> >>>> >>>> The following commit(s) were added to refs/heads/master by this push: >>>> new 8dd0dde Add javax.(decorator|enterprise|inject) as ones which >>>> should be migrated >>>> 8dd0dde is described below >>>> >>>> commit 8dd0dde9e030e8168141184b3e51de1d674aee0b >>>> Author: Martin Tzvetanov Grigorov <mgrigo...@apache.org> >>>> AuthorDate: Thu Mar 12 16:09:04 2020 +0200 >>>> >>>> Add javax.(decorator|enterprise|inject) as ones which should be >>>> migrated >>>> >>>> Those are needed for CDI applications >>>> >>> >>> Well, it's needed if there is a jakarta implementation of CDI [do you >>> have one ? ...]. Right now that's not the case and it will mess things up >>> since it's possible to use Tomcat 10 with a javax CDI and a converted >>> webapp. >>> See the modules/owb wrapper for example. >>> >> >>> So it's a bit messy and this would need to be configurable for now. >>> >> >> Here is how I understand it: >> 1) if you deploy in EE server, like Wildfly and Glassfish, then both >> cdi-api.jar and the CDI impl (like weld-servlet.jar) are provided by the EE >> server and they are not part of the application, so nothing will be migrated >> 2) if you deploy in web container, like Tomcat & Jetty, then cdi-api.jar >> and weld-servlet.jar should be in the application's WEB-INF/lib/, so both >> are migrated and everything works >> >> In both cases one is supposed to deploy in Jakarta EE 9 container, i.e. >> jakarta packages are prefered than javax ones. >> >> Do you see a use case that is not supported at the moment ? >> > > There's no point in migrating code that doesn't need to be migrated, so I > don't understand what you are using this for. If the user is using a > package like modules/owb, then it won't work. > You neither explain a breaking use case nor modules/owb has any documentation :-/ But I will take your word and revert my change. If we should follow Romain's suggestion then probably ejb, mail, persistence and transaction should not be in this regexp as well. Martin > > Rémy > > >> >> Martin >> >> >>> >>> Rémy >>> >>> >>>> --- >>>> src/main/java/org/apache/tomcat/jakartaee/Util.java | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/src/main/java/org/apache/tomcat/jakartaee/Util.java >>>> b/src/main/java/org/apache/tomcat/jakartaee/Util.java >>>> index 21e0fbf..701134d 100644 >>>> --- a/src/main/java/org/apache/tomcat/jakartaee/Util.java >>>> +++ b/src/main/java/org/apache/tomcat/jakartaee/Util.java >>>> @@ -23,7 +23,8 @@ import java.util.regex.Pattern; >>>> public class Util { >>>> >>>> private static Pattern PATTERN = Pattern.compile( >>>> - >>>> "javax([/\\.](annotation|ejb|el|mail|persistence|security[/\\.]auth[/\\.]message|servlet|transaction|websocket))"); >>>> + >>>> "javax([/\\.](annotation|decorator|ejb|el|enterprise|inject|mail|persistence|security[/\\.]auth[/\\" >>>> + + ".]message|servlet|transaction|websocket))"); >>>> >>>> /** >>>> * Get the extension of a filename >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>>> >>>>
