Thanks Arjan, I'll have a look and will let you know (outside of this list, if WF is not affected).<div><br><div class="gmail_quote"><div dir="ltr">El mar., 3 abr. 2018 20:49, arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 3, 2018 at 6:48 PM, Guillermo González de Agüero <span dir="ltr"><<a href="mailto:z06.guillermo@gmail.com" target="_blank">z06.guillermo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="m_6231572804441866482gmail-"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>So if the application is not actually using JSF, that's all it does. And there should not be any additional overhead. If the application does use JSF indeed, there's overhead and that's indeed too much overhead. I've been trying on reducing this, for instance by using a pre-parsed internal faces-config file.</div></div></blockquote></div></span><div>But the implementation is on the classpath, so there will always be some JSF related class there. Stuart changes will fix this, but Payara suffers from this same problem as far as I saw. In fact I had this issue on my queue on pending reports.</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The Mojarra classes itself are not scanned in the case of a Java EE application server. </div><div><br></div><div>Specifically for Mojarra and Payara (Micro) I ran quite a few tests and compared performance with a JSF class present in the application and without. The difference was immediate obvious, so that clearly indicates a lot of work is not done if the application doesn't contain a JSF class. You could of course try to double check this.</div><div><br></div><div>I'm not sure which issue you saw, but if there's indeed an issue I would be all to happy to try to solve it.</div><div><br></div><div>Maybe you are confused with the admin console though? The Payara admin console uses JSF, so you'll see it being initialising for that, but not for the application (it prints out the context for which it initialises, so you could take a look at that).</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>><span style="font-size:12.800000190734863px">The fact is FacesInitializer also looks for a lot of annotation, but I see you duplicated that checks so it should be perfectly valid.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="font-size:12.800000190734863px">It doesn't so much look explicitly for annotations. It used to do that, but now it just uses the set of classes passed into the ServletContainerInitializer. Of course the declaration of the classes the </span><span style="font-size:12.800000190734863px">FacesInitializer is interested in</span><span style="font-size:12.800000190734863px"> means that the Servlet container may need to do some extra work, but since a Servlet container already scans all application classes (to find @WebServlet etc), this is maybe not that much extra work.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">For JSF 3.0 we should maybe only look for @FacesConfig and faces-config.xml, but that's still a bit out into the future.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Kind regards,</span></div><div><span style="font-size:12.800000190734863px">Arjan</span></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="m_6231572804441866482gmail-HOEnZb"><div class="m_6231572804441866482gmail-h5"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>See specifically this commit: <a href="https://github.com/javaserverfaces/mojarra/commit/0129ffe2aadb4e87f46d094159cee0910f73003a" target="_blank">https://github.com/javaserverfaces/mojarra/commit/0129ffe2aadb4e87f46d094159cee0910f73003a</a></div><div><br></div><div>@Stuart, I wonder what the overhead is that you see when the application is not using JSF, and which test application you are actually using. Could it be that you somehow have a FacesServlet or faces-config.xml etc anyway?</div><div><br></div><div>Kind regards,</div><div>Arjan</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 3, 2018 at 7:50 AM, Guillermo González de Agüero <span dir="ltr"><<a href="mailto:z06.guillermo@gmail.com" target="_blank">z06.guillermo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>This would be great to have!</div><div><br></div><div>As for JSF activation, note that faces-config.xml nor Faces Servlet are required anymore. There's also a new @FacesConfig CDI qualifier on JSF 2.3 which substitutes faces-config.</div><div><br></div><div>Looking at FacesConfigInitializer class[1] might provide some more insight. I've always been puzzled with the "Initializing Mojarra" log when deploying a JAX-RS only app. The mentioned class supposedly should prevent JSF from unnecessary initializing. Perhaps some work could be done there which helps also other runtimes?</div><div><br></div><div>Btw, I think he is already subscribed to the list, but I'm cc'ing Arjan Tijms since he's the expert on this stuff.</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>Guillermo González de Agüero<br></div><div><br></div><div>[1] <a href="https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/faces/config/FacesInitializer.java" target="_blank">https://github.com/javaserverfaces/mojarra/blob/4ea1679838f5a6bf6899c282964ff241c020e2f9/impl/src/main/java/com/sun/faces/config/FacesInitializer.java</a><br></div><div><br><div class="gmail_quote"><div><div class="m_6231572804441866482gmail-m_5412684118476676885m_-504821852076042886h5"><div dir="ltr">El mar., 3 abr. 2018 a las 3:16, Stuart Douglas (<<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>>) escribió:<br></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="m_6231572804441866482gmail-m_5412684118476676885m_-504821852076042886h5"><div dir="ltr">Hi Everyone,<div><br></div><div>At the moment JSP and JSF are being activated for all web deployments, which is relatively expensive as this involves quite a bit of class loading and TLD parsing. </div><div><br></div><div>To give an idea about how much time this is actually taking I did a test with a large number of small servlet only deployments both with and without JSF, and JSF was accounting for 20% of total deployment time even though it was not actually used by any of the deployments.</div><div><br></div><div>It also had a significant effect on memory usage, as the parsed TLD's are retained, and are quite large.</div><div><br></div><div>The root of this issue is that the spec does not define clear activation criteria for these technologies. I am proposing that we formalise some activation criteria, so that we can avoid activating them if they are not required.</div><div><br></div><div>JSP:</div><div><br></div><div>For JSP I think we can use the following criteria (if either one is satisfied JSP is activated):</div><div><br></div><div>- The presence of a JSP file mapping in web.xml</div><div>- The presence of JSP files inside the deployment</div><div>- The presence of JSF</div><div><br></div><div>One thing that does concern me is that searching for JSP files in this way may be expensive in large deployments with lots of web resources. An alternate approach may be to try and make JSP lazy, so class loading and TLD passing does not happen until a request for a JSP file arrives.</div><div><br></div><div><br></div><div>JSF:</div><div><br></div><div>This is much less clear. I think we can use the presence of one of the following:</div><div><br></div><div>- faces-config.xml</div><div>- The faces servlet in web.xml</div><div>- Something else?</div><div><br></div><div>I am not really sure what effect this will have on backwards compatibility though. If this is a compatibility problem we could add an attribute to the JSF subsystem to restore the old mode.</div><div><br></div><div><br></div><div>Does this sound reasonable? </div><div><br></div><div>Stuart</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div><span>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></span></blockquote></div></div></div>
</blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div></div></div></blockquote></div></div>