Re: [jbossws-dev] Deprecated of java.endorsed.dirs in JDK8
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