<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=SL link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=EN-US>I am more in favor of option 2. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>As long as we can make it work.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>We already tried moving to JAXP completely quite recently, but we did stumble upon few issues. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Mostly related to not fully compatible JAXP factory classes used by some of EE spec APIs <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>which haven’t been updated in a while. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>One of such was SAAJ api <a href="https://github.com/jboss/jboss-saaj-api_spec">https://github.com/jboss/jboss-saaj-api_spec</a><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Along with few others in the webservices area.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>If we can make it work going forward, it will probably be best benefit for us all.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>I don’t think deployments themselves pose any big issues now days. <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Bigger problems are libraries / subsystems that we integrate. Especially some more arcane parts of EE stack.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>--<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>tomaz<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>From: </b><a href="mailto:david.lloyd@redhat.com">David Lloyd</a><br><b>Sent: </b>torek, 05. december 2017 17:43<br><b>To: </b><a href="mailto:wildfly-dev@lists.jboss.org">WildFly Dev</a><br><b>Subject: </b>[wildfly-dev] Java 9, JBoss Modules, JAXP Redirection</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>JBoss Modules has a redirection mechanism for JAXP that allows us to</p><p class=MsoNormal>override the default provider with one from a module, while still</p><p class=MsoNormal>allowing TCCL-based selection to occur. Since Java 9, our</p><p class=MsoNormal>implementation violates the stricter reflection rules that are now in</p><p class=MsoNormal>place, meaning that JBoss Modules will probably stop working in a</p><p class=MsoNormal>future version. We had hoped that Java 9 would have some useful way</p><p class=MsoNormal>to establish the default implementation of various JAXP factories, but</p><p class=MsoNormal>that never happened. So I want to take the opportunity to review a</p><p class=MsoNormal>few mitigation options and get some feedback.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Option 1: Fix the redirection facility in Java 9</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Java 9 offers a "newDefaultFactory()" method on most (maybe all) of</p><p class=MsoNormal>the JAXP factory classes, which always simply instantiates the system</p><p class=MsoNormal>provider of the given function. Using this method should allow us to</p><p class=MsoNormal>bypass the now-disallowed reflection by switching all of the cached</p><p class=MsoNormal>Constructor<? extends T> fields with cached Supplier<T> fields, whose</p><p class=MsoNormal>implementation would either be a call to the appropriate</p><p class=MsoNormal>newDefaultFactory() or a service loader-style public Constructor call.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Pros:</p><p class=MsoNormal>• Less change</p><p class=MsoNormal>• We can still override the default JAXP implementation</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Cons:</p><p class=MsoNormal>• Continue carrying around the baggage of the __redirected code</p><p class=MsoNormal>until/unless the JAXP spec is modified to allow setting the default</p><p class=MsoNormal>factories</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Option 2: Stop using redirection in Java 9, "cold turkey"</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We could delete these classes completely. Instead of setting the</p><p class=MsoNormal>default JAXP implementation, we ensure that any modules using JAXP</p><p class=MsoNormal>have a services dependency on the implementation(s) corresponding to</p><p class=MsoNormal>those APIs, carefully monitoring TCCL setup and usage or ensuring that</p><p class=MsoNormal>the newFactory(xxx, getClass().getClassLoader()) form is always used,</p><p class=MsoNormal>depending on the situation.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Pros:</p><p class=MsoNormal>• No more dealing with redirection ever again</p><p class=MsoNormal>• While deployments generally use the newFactory() form, but</p><p class=MsoNormal>deployments also have TCCL set so that's not a problem</p><p class=MsoNormal>• One less source of bugs</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Cons:</p><p class=MsoNormal>• It may be hard to be sure that we've done this 100% correctly in all</p><p class=MsoNormal>cases outside of deployments; the results could be weird mixed</p><p class=MsoNormal>implementations</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Option 3: Use a dependency strategy</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>We could cause JBoss Modules to always include a "hidden" last</p><p class=MsoNormal>dependency on our chosen default JAXP implementation, which in turn</p><p class=MsoNormal>could be set up by a service loader configuration in the boot module.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Pros:</p><p class=MsoNormal>• Simpler than redirection</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Cons:</p><p class=MsoNormal>• Due to the way JAXP works, we have to pollute the target module's</p><p class=MsoNormal>namespace with the implementation classes (though with redirection</p><p class=MsoNormal>we've already done that via __redirected classes)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>So far Option 1 is (unfortunately) still looking the best to me,</p><p class=MsoNormal>overall. Does anyone have any differing opinions on this?</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-- </p><p class=MsoNormal>- DML</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>_______________________________________________</p><p class=MsoNormal>wildfly-dev mailing list</p><p class=MsoNormal>wildfly-dev@lists.jboss.org</p><p class=MsoNormal>https://lists.jboss.org/mailman/listinfo/wildfly-dev</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>