Re: [jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
Sorry, didn't mean to request a rollback, was merely trying to highlight
areas likely affected by the change.
--
Regards,
Igor
On Thu, Aug 24, 2017, at 12:33 PM, Robert Scholte wrote:
> Hi Igor,
>
> moving this to dev-list.
> I've asked an explanation of the Java developers team. They confirm that
> they've made a more clear separation of boot-, system- and
> application-classloader. They wondered why we put "null" there in the
> first place, because in general the boot classloader is not enough.
> I've tested if and this change would be the required fix for MANTRUN-200.
> I haven't found any failing tests yet.
> If this causes issues for other frameworks we need to have a look what
> should be changed combined with the impact. Were they relying on a bug in
> Maven. Based on the analysis so far this should be the proper fix.
> Can you somehow try to verify first if this is really an issue. I'm not
> sure if this should be reverted because of _potential_ issues, because in
> the end every change could result in new issues.
>
> I'll try to prepare new Maven installation locally and run other Maven
> subprojects as well.
>
> thanks,
> Robert
>
> ps Stephen gave me the +1 for merging.
>
>
> On Thu, 24 Aug 2017 14:30:00 +0200, Igor Fedorenko (JIRA)
> wrote:
>
> >
> > [
> > https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16139975#comment-16139975
> >
> > ]
> >
> > Igor Fedorenko commented on MNG-6275:
> > -
> >
> > I don't have time to do proper analysis of this, but this change will
> > likely cause problems in m2e, plugin testing, jenkins and other embedded
> > usecases, where contents of system classloader is generally unknown and
> > can contain classes that either collide or confuse plugins in some other
> > ways (e.g. random/unrelated components visible to plugins in only some
> > environments, which will be very hard to troubleshoot).
> >
> > PS: didn't we agree to get all core changes reviewed and +1'ed by at
> > least one other developer before pushing to master?
> >
> >> ServiceLoaderFactory can't find implementations via ClassRealm
> >> --
> >>
> >> Key: MNG-6275
> >> URL: https://issues.apache.org/jira/browse/MNG-6275
> >> Project: Maven
> >> Issue Type: Bug
> >> Components: Class Loading
> >>Reporter: Robert Scholte
> >>Assignee: Robert Scholte
> >>Priority: Critical
> >> Fix For: 3.5.1
> >>
> >>
> >> Spotted this issue via MANTRUN-200. The reason is that in the
> >> {{DefaultClassRealmManager}} a new realm is created where the parent
> >> classLoader is {{null}}. This implies that the bootstrap classloader is
> >> used as parent.
> >> With Java8 nashorn has become an extension and is not part of the
> >> bootstrap classloader anymore.
> >> It is kind of strange that we want the bootstrap classloader here, it
> >> makes more sense if the system classloader is used (but with Java 7 and
> >> older versions of Java this was not an issue, both worked fine).
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.4.14#64029)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
Hi Igor,
moving this to dev-list.
I've asked an explanation of the Java developers team. They confirm that
they've made a more clear separation of boot-, system- and
application-classloader. They wondered why we put "null" there in the
first place, because in general the boot classloader is not enough.
I've tested if and this change would be the required fix for MANTRUN-200.
I haven't found any failing tests yet.
If this causes issues for other frameworks we need to have a look what
should be changed combined with the impact. Were they relying on a bug in
Maven. Based on the analysis so far this should be the proper fix.
Can you somehow try to verify first if this is really an issue. I'm not
sure if this should be reverted because of _potential_ issues, because in
the end every change could result in new issues.
I'll try to prepare new Maven installation locally and run other Maven
subprojects as well.
thanks,
Robert
ps Stephen gave me the +1 for merging.
On Thu, 24 Aug 2017 14:30:00 +0200, Igor Fedorenko (JIRA)
wrote:
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16139975#comment-16139975
]
Igor Fedorenko commented on MNG-6275:
-
I don't have time to do proper analysis of this, but this change will
likely cause problems in m2e, plugin testing, jenkins and other embedded
usecases, where contents of system classloader is generally unknown and
can contain classes that either collide or confuse plugins in some other
ways (e.g. random/unrelated components visible to plugins in only some
environments, which will be very hard to troubleshoot).
PS: didn't we agree to get all core changes reviewed and +1'ed by at
least one other developer before pushing to master?
ServiceLoaderFactory can't find implementations via ClassRealm
--
Key: MNG-6275
URL: https://issues.apache.org/jira/browse/MNG-6275
Project: Maven
Issue Type: Bug
Components: Class Loading
Reporter: Robert Scholte
Assignee: Robert Scholte
Priority: Critical
Fix For: 3.5.1
Spotted this issue via MANTRUN-200. The reason is that in the
{{DefaultClassRealmManager}} a new realm is created where the parent
classLoader is {{null}}. This implies that the bootstrap classloader is
used as parent.
With Java8 nashorn has become an extension and is not part of the
bootstrap classloader anymore.
It is kind of strange that we want the bootstrap classloader here, it
makes more sense if the system classloader is used (but with Java 7 and
older versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Declaration of intent to release 3.5.1
On Thu 24 Aug 2017 at 10:16, Robert Scholte wrote: > Great news! > > Unresolved issues for Maven 3.5.x[1] > I don't see any critical issues here which are regressions in 3.5.0 > > There's one issue I would like to merge, though needs to be second first. > In case of ServiceLoaders it is a Java 8+ issue: > MNG-6275: ServiceLoaderFactory can't find implementations via ClassRealm[2] > Commit[3] > Jenkins Happiness[4] (it's red because there is no matching > maven-integration branch, new unittest is green) > Seconded > thanks, > Robert > > [1] https://s.apache.org/maven-3.5.1-RC_jira > [2] https://issues.apache.org/jira/browse/MNG-6275 > [3] > https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=c829bdcf > [4] https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6275/1/ > > > On Wed, 23 Aug 2017 21:09:03 +0200, Stephen Connolly > wrote: > > > Advance warning, my intent is to start cutting RCs towards the end of > > next > > week. > > > > Focus on bugs and Java 9 compatibility would be best at this stage > > > > (Getting to an actual release will take as long as it takes, but I intend > > actively triage of the scope and RCs every 1-2 weeks until we get there) > > > > -Stephen > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: [ANN] Declaration of intent to release 3.5.1
Great news! Unresolved issues for Maven 3.5.x[1] I don't see any critical issues here which are regressions in 3.5.0 There's one issue I would like to merge, though needs to be second first. In case of ServiceLoaders it is a Java 8+ issue: MNG-6275: ServiceLoaderFactory can't find implementations via ClassRealm[2] Commit[3] Jenkins Happiness[4] (it's red because there is no matching maven-integration branch, new unittest is green) thanks, Robert [1] https://s.apache.org/maven-3.5.1-RC_jira [2] https://issues.apache.org/jira/browse/MNG-6275 [3] https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=c829bdcf [4] https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6275/1/ On Wed, 23 Aug 2017 21:09:03 +0200, Stephen Connolly wrote: Advance warning, my intent is to start cutting RCs towards the end of next week. Focus on bugs and Java 9 compatibility would be best at this stage (Getting to an actual release will take as long as it takes, but I intend actively triage of the scope and RCs every 1-2 weeks until we get there) -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Declaration of intent to release 3.5.1
I'm still technically on vacation until Tuesday... just not out of the country... but my wife would kill me just the same if I try to do anything on the computer before then ;-) On Thu 24 Aug 2017 at 06:54, Hervé BOUTEMY wrote: > thank you Stephen: vacations are over for everybody! :) > > Regards, > > Hervé > > Le mercredi 23 août 2017, 19:09:03 CEST Stephen Connolly a écrit : > > Advance warning, my intent is to start cutting RCs towards the end of > next > > week. > > > > Focus on bugs and Java 9 compatibility would be best at this stage > > > > (Getting to an actual release will take as long as it takes, but I intend > > actively triage of the scope and RCs every 1-2 weeks until we get there) > > > > -Stephen > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
