From rsvoboda at redhat.com Thu Jul 2 05:14:33 2015 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Thu, 2 Jul 2015 05:14:33 -0400 (EDT) Subject: [jbossws-dev] Deprecated of java.endorsed.dirs in JDK8 In-Reply-To: <55941336.2050702@redhat.com> References: <895496978.25336970.1435685479355.JavaMail.zimbra@redhat.com> <5593AB80.9020000@redhat.com> <175376172.11115817.1435750524936.JavaMail.zimbra@redhat.com> <55941336.2050702@redhat.com> Message-ID: <55158739.11641337.1435828473272.JavaMail.zimbra@redhat.com> ccing jbossws-dev list so we have it tracked > On 01/07/15 13:35, Rostislav Svoboda wrote: > >> In terms of action items, we should probably consider having a look at > >> JDK9 in the next future and start getting an idea of what to do... > >> > > I think we need to have solution for EAP 7.0.0 as java.endorsed.dirs is > > deprecated now and will be removed in JDK 9 ... > > I'm almost sure PM will ask us to re-certify EAP 7.0.0 GA on JDK 9 as it > > should be GA on 2016-09-22. > > Another option would be to target JDK 9 support for EAP 7.1.0 GA. > > > > Rostislav > > See https://issues.jboss.org/browse/JBWS-3927 +1 for this task comment to " ... and possibly restricting the supported JDKs from now on ..." This may won't be so easy from product perspective ... in EAP 6 we support 3 major JDK versions For EAP 7 it may be the same number, at least JDK 8 + 9. > Besides for what's in the jira description, the idea is that what we can > do now is ensuring that the JBossWS testsuite as well as any other > properly configured client can work fine without having to endorse > anything. By properly configured I mean either using JBoss Modules or Seems safer, something like java -jar $JBOSS_HOME/jboss-modules.jar -mp $JBOSS_HOME/modules/ -cp target/classes/ -dep org.jboss.ws.cxf.jbossws-cxf-client org.jboss.MyClient is possible now Not sure how this would work for TS > with a flat classpath in which the jbossws jars come before the cxf > ones. Note, the latter condition equals to a maven project in which the > jbossws dependencies come before cxf dependencies and/or any other > dependency that transitively pulls the cxf ones. Nasty problems can come up from this, we need to be careful, checks are good idea for this approach > Further efforts might be spent in the future when JDK 9 support will be > worked, to either enforce modular classloading (perhaps through Jigsaw we need solution for both JDK 8 and 9 - so I would prefer JBoss Modules Understand that Jigsaw would be in JDK by default + would be widely used > stuff) or to add checks on the classpath at runtime (with the goal of +100 Rostislav > warning the user if he's not properly using jbossws... this needs better > thinking though). > > Cheers > Alessio > > > -- > Alessio Soldano > Web Service Lead, JBoss > > From asoldano at redhat.com Thu Jul 2 06:15:30 2015 From: asoldano at redhat.com (Alessio Soldano) Date: Thu, 02 Jul 2015 12:15:30 +0200 Subject: [jbossws-dev] Deprecated of java.endorsed.dirs in JDK8 In-Reply-To: <55158739.11641337.1435828473272.JavaMail.zimbra@redhat.com> References: <895496978.25336970.1435685479355.JavaMail.zimbra@redhat.com> <5593AB80.9020000@redhat.com> <175376172.11115817.1435750524936.JavaMail.zimbra@redhat.com> <55941336.2050702@redhat.com> <55158739.11641337.1435828473272.JavaMail.zimbra@redhat.com> Message-ID: <55950F42.3070805@redhat.com> On 02/07/15 11:14, Rostislav Svoboda wrote: > ccing jbossws-dev list so we have it tracked > >> On 01/07/15 13:35, Rostislav Svoboda wrote: >>>> In terms of action items, we should probably consider having a look at >>>> JDK9 in the next future and start getting an idea of what to do... >>>> >>> I think we need to have solution for EAP 7.0.0 as java.endorsed.dirs is >>> deprecated now and will be removed in JDK 9 ... >>> I'm almost sure PM will ask us to re-certify EAP 7.0.0 GA on JDK 9 as it >>> should be GA on 2016-09-22. >>> Another option would be to target JDK 9 support for EAP 7.1.0 GA. >>> >>> Rostislav >> See https://issues.jboss.org/browse/JBWS-3927 > +1 for this task > > comment to " ... and possibly restricting the supported JDKs from now on ..." > This may won't be so easy from product perspective ... in EAP 6 we support 3 major JDK versions > For EAP 7 it may be the same number, at least JDK 8 + 9. To clarify, the issue is that if you can't change the JAX-WS api level through endorsing so that it's 2.2, you need to use a JDK that already has jaxws 2.2, which basically means JDK 7 at least. We're OK atm, in the future things could possibly change though (even if I don't realistically think we'll have new JAX-WS api minors in the next future) >> Besides for what's in the jira description, the idea is that what we can >> do now is ensuring that the JBossWS testsuite as well as any other >> properly configured client can work fine without having to endorse >> anything. By properly configured I mean either using JBoss Modules or > Seems safer, something like java -jar $JBOSS_HOME/jboss-modules.jar -mp $JBOSS_HOME/modules/ -cp target/classes/ -dep org.jboss.ws.cxf.jbossws-cxf-client org.jboss.MyClient is possible now > Not sure how this would work for TS It would work, but we can't expect users to run any jaxws client app this way. So I prefer keeping the TS as is for now, given it's still safe because we control the maven dependencies / classpath. >> with a flat classpath in which the jbossws jars come before the cxf >> ones. Note, the latter condition equals to a maven project in which the >> jbossws dependencies come before cxf dependencies and/or any other >> dependency that transitively pulls the cxf ones. > Nasty problems can come up from this, we need to be careful, checks are good idea for this approach Sure, that's why we advertised the endorsing approach in the past. >> Further efforts might be spent in the future when JDK 9 support will be >> worked, to either enforce modular classloading (perhaps through Jigsaw > we need solution for both JDK 8 and 9 - so I would prefer JBoss Modules > Understand that Jigsaw would be in JDK by default + would be widely used The point is that it would be standard. In any case, the JBoss Modules solution is already available (we have few tests in the testsuite that use it), but we are not going to convert the whole testsuite (at least not now), for the reasons mentioned above. > >> stuff) or to add checks on the classpath at runtime (with the goal of > +100 Here we'll have to find the possible entry points where to run the checks (you basically have to figure out which JBossWS class the user could possibly end up using expecting the JBossWS integration to be properly in place while it actually isn't). Additionally, we could have the check run on request by the users. Cheers Alessio -- Alessio Soldano Web Service Lead, JBoss