[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [glassfish-dev] [External] : Re: Where, if, to include javax.xml.bind API?
|
Hi,
On 3/17/21, 6:36 PM, "glassfish-dev on behalf of arjan tijms" <glassfish-dev-bounces@xxxxxxxxxxx on behalf of arjan.tijms@xxxxxxxxx> wrote:
Hi,
There's another option, and that's to unpack the source archive and recompile during the build:
that's basically what I've done[1]. But instead of modifying 3rd party dependency which is non-trivial to rebuild (I'd need new CQ for xalan, which we don't need otherwise, probably new CQ for santuario itself to by allowed to redistribute its modified version and adding xjc calls to the build), I've relocated only com.sun.activation package and thus modified only Jakarta EE owned code[2]
Other alternative, which is not what we/GF want(s) would be to rely on JDK provided version - this would have (at least) 3 drawbacks - it's faster to release new version of Metro than request people to upgrade JDK if there is a security issue found in Santuario (and that happens from time to time), Metro depends on some of its internals, which are not accessible on JPMS, and we would need to re-export few packages from JDK in order to use them in OSGi. OSGi is also the main reason, why is santuario packaged within the webservices-osgi.jar - some versions did not have correct headers and there used to be problems getting it running properly. But this in particular may have changed already.
thanks,
--lukas
[1]: https://github.com/eclipse-ee4j/metro-wsit/blob/master/wsit/bundles/webservices-osgi/pom.xml#L96
[2]: https://github.com/eclipse-ee4j/metro-wsit/blob/master/wsit/bundles/webservices-osgi/pom.xml#L251
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
<executions>
<execution>
<id>get-commons-fileupload-sources</id>
<phase>process-sources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
<classifier>sources</classifier>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/fileupload-source</outputDirectory>
</artifactItem>
<artifactItem>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.8.0</version>
<classifier>sources</classifier>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/fileupload-source</outputDirectory>
</artifactItem>
</artifactItems>
<excludes>org/apache/commons/fileupload/portlet/*</excludes>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.1.0</version>
<executions>
<execution>
<id>add-commons-fileupload-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/fileupload-source</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.3</version>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>replace</goal>
</goals>
</execution>
</executions>
<configuration>
<includes>
<include>${project.build.directory}/fileupload-source/**/*.java</include>
</includes>
<replacements>
<replacement>
<token>javax.servlet</token>
<value>jakarta.servlet</value>
</replacement>
</replacements>
</configuration>
</plugin>
On Wed, Mar 17, 2021 at 2:11 AM Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> wrote:
Hi Steve,
On 3/16/21, 10:18 AM, "glassfish-dev on behalf of Steve Millidge (Payara)" <glassfish-dev-bounces@xxxxxxxxxxx on behalf of steve.millidge@xxxxxxxxxxx> wrote:
Hi Lukas,
(1) isn't in place although maybe you can run the jar through transformer and publish it in new maven coordinates or in one of your jars as part of the metro project?
this would be the best but it's not something I'm able to do in few hours :-(
(3) is better than the others if (1) isn't possible.
I took this path and you can expect PR updating Metro to 3.0.1-b01 when I wake up (finally!)
Has there been any upstream work on moving to Jakarta?
I've already submitted PR to Santuario long time ago (and updated it today) but it does not look like they will accept it anytime soon.
thanks,
--lukas
Steve
-----Original Message-----
From: glassfish-dev <glassfish-dev-bounces@xxxxxxxxxxx> On Behalf Of Lukas Jungmann
Sent: 15 March 2021 22:39
To: glassfish developer discussions <glassfish-dev@xxxxxxxxxxx>
Subject: [glassfish-dev] Where, if, to include javax.xml.bind API?
Hi,
as I work through Metro & JDK 11 I've spotted one thing I'm not sure about the best way to resolve.
Problem:
Metro uses Apache Santuario for XML security which has not been updated to Jakarta namespace yet[1], so it depends on pre-jakarta XML Binding runtime implementation (and activation) and thus also corresponding version of the API, the one with javax namespace. That API is there in JDK 8 and till now it could have been taken from there when needed. But on JDK 11, this fallback won't work and in the best case, relevant functionality just does not work, in the worst case, some TCK tests are impacted by inability of resolution of few classes somewhere during execution, in short they are just failing.
Possible solutions:
1) use Eclipse Transformer or some other similar solution for this - maybe that is already in place?
2) keep the status quo and hope no TCKs are failing due to this
3) mitigate the risk by inclusion of "old" javax version of the APIs together with "old" xml binding runtime in the webservices-osgi.jar - inclusion of the API can be tricky since the "jakarta" artifact with "javax" classes needs to be used but one cannot use two different versions of the artifact with the same groupId/artifactId (I think I can get around this limitation); inclusion of both versions of runtime at once in one jar should be ok since the new runtime uses different packages (org.glassfish.jaxb vs com.sun.xml.bind). There are some colliding classes further down the road but that should not be that critical from the "old" xml binding runtime point of view.
4) "somehow" put old APIs and runtime directly in GFs modules directory and made them visible to and consumable by the "outside world"
I personally prefer going with option 3 - hiding the old API and runtime in place where it is needed but since this has impact on GF as such, I'd like to here you opinion(s), thoughts and/or advices on how to proceed with this. Or just tell me it's already solved (ie through option 1) and I'll be happy
Thanks,
--lukas
[1]: https://urldefense.com/v3/__https://issues.apache.org/jira/browse/SANTUARIO-548__;!!GqivPVa7Brio!JL8rlbOCSarN8iVzPJJImVcIdWnKaXmAYdn1AV8KBunZHLRCDzbsjvVs7xEEfKs9nj8$
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!JL8rlbOCSarN8iVzPJJImVcIdWnKaXmAYdn1AV8KBunZHLRCDzbsjvVs7xEE4MUgB7s$
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!JL8rlbOCSarN8iVzPJJImVcIdWnKaXmAYdn1AV8KBunZHLRCDzbsjvVs7xEE4MUgB7s$
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!PVCyTCK4OYeu8cxan6amVeOnXyPwHFRuGNhBcaCIWqb_EDnjF1sMEu39IavzZEsplf8$>
