[jbossws-dev] Deprecated of java.endorsed.dirs in JDK8

[Alessio Soldano]

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