Bootsfaces renderers not being called #732
Comments
|
Awesome analysis, thanks! I suppose Payara uses Mojarra. If so, add a breakpoint to the method Other ideas:
|
|
BTW, you've mentioned that you deploy an EAR. What happens if you deploy a simple WAR file instead? |
|
Stephan- thanks for so many good suggestions so quickly! I will definitely try those breakpoints. At the moment, the EAR is working perfectly (of course!), so I will have to wait until it fails again. As to EAR- Tom's project is a WAR and he is seeing the same behavior, so I don't think it's likely to be a packaging issue. One other thing I do notice is that when the app is failing, the screen comes back very very fast. Much faster than when it is working correctly. The difference is only a second or two, but it seems like the speed may be because the renderer is skipping things. Just one more piece of the puzzle to mull over... Thanks again!! |
|
Did you have any progress? BTW, is it possible to switch temporarily to another application server for testing purposes? I'd like to check whether it's a specific Payara problem, or whether it's a general problem. |
|
Still waiting for next failure, should be coming up ;) We have seen same
behavior on Glassfish 4.1.1 and Payara. (Those are the only two we have.) I
also just for the heck of it tried the non-delegating classloader option on
Payara but no difference. Will keep you posted!
…On Wed, Apr 26, 2017 at 3:55 PM, Stephan Rauh ***@***.***> wrote:
Did you have any progress? BTW, is it possible to switch temporarily to
another application server for testing purposes? I'd like to check whether
it's a specific Payara problem, or whether it's a general problem.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#732 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AWnQ5EPzI-0OMpy_EKAjkinU1GXjhRAAks5rz6ErgaJpZM4NHmTm>
.
|
|
Just now having the issue again- will try your debugging ideas! |
|
I have been able to do some extensive debugging and can see the problem, but I don't understand the cause of it. To bring you up to date: Today I started Payara which had three simple Bootsfaces apps that had been deployed and were working perfectly yesterday. Today when Payara came up, none of the apps would display any Bootsfaces components. So in other words, without rebuilding or even redeploying any of the apps, they suddenly failed to display the Bootsfaces components. (All three apps, which are not directly related to each other.) Rebuilding or redeploying any of the apps did not help. From debugging per your suggestions, I can see that the Bootsfaces component constructors are being called correctly, and ApplicationImpl::newThing seemed to be finding them just fine. However, as before, none of the renderers were being called. In debugging the Faces RenderResponsePhase class, I could see that all of the non-Bootsfaces components were being rendered correctly. Within UIComponentBase.encodeBegin(), the code is trying to render a particular component- in this case a net.bootsfaces component. It asks to get the RenderKit for the current context. The RenderKit it selects is HTML_BASIC. (Is this what you would expect?) When it queries this RenderKit for the component renderer by Family (net.bootsfaces) and rendererType (navBar in this case), the "net.bootsfaces" renderers are not present in the list of families, so no renderer is found. I took a screen shot of the renderers that were listed and I will try to attach it here. (You will see the org.primefaces family listed- by now the project has added the Signature component from PF, but keep in mind that this problem can be observed on any project with or without other component libraries.) The question is: Why is the net.bootsfaces component family missing from the list for the RenderKit? Obviously without this registration, none of the components will render. Is HTML_BASIC the render kit you would expect to be used? It would seem that there may be a problem with how Bootsfaces registers its renderer "family" with the context, and this problem seems to survive multiple undeploy/deploy actions. (I haven't yet tried restarting Payara because I wanted to capture the problem and really probe it before it disappeared.) It looking at various other classes during the debugging, it does seem that the system knows about Bootsfaces. It is just the renderer family registration that is missing. Which part of the code is responsible for registering the renderer family with the context? If you want I can debug it some more, placing breakpoints there, etc. Let me know, thanks! |
|
|
|
I'm puzzled. We're using annotations to define the renderers. From a technical perspective, we could define a default renderer, ignoring the standard detection mechanism. But that's only the last resort. This is the definition of the renderer: @FacesRenderer(componentFamily = "net.bootsfaces.component", rendererType = "net.bootsfaces.component.badge.Badge")
public class BadgeRenderer extends CoreInputRenderer {and this is how the component links to it: @FacesComponent(Badge.COMPONENT_TYPE)
public class Badge extends BadgeCore implements net.bootsfaces.render.IHasTooltip, net.bootsfaces.render.IResponsive {
public static final String COMPONENT_TYPE = C.BSFCOMPONENT + ".badge.Badge";
public static final String COMPONENT_FAMILY = C.BSFCOMPONENT;
public static final String DEFAULT_RENDERER = "net.bootsfaces.component.badge.Badge";
public Badge() {
AddResourcesListener.addThemedCSSResource("core.css");
//!bs-less//AddResourcesListener.addThemedCSSResource("badges.css");
setRendererType(DEFAULT_RENDERER);
}
public String getFamily() {
return COMPONENT_FAMILY;
}In theory, we can also do without the DEFAULT_RENDERER. Do you have the source code version of BootsFaces at hand? If so, can you check what happens if you remove the line setting the default renderer in the constructor? |
|
Hi Stephan, |
|
The class you're looking for is |
|
When does that code get run? |
|
It's run when the container starts. Probably, restarting the domain or redeploying the application does the trick, too.
… Am 02.05.2017 um 23:00 schrieb jimmc929 ***@***.***>:
When does that code get run?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Hi Stephan, Jim /**
* Register the Bootsfaces renderers
*/
private void initializeBootsfacesRenderers() {
// Loop through all of the Bootsfaces components
for (ComponentsEnum value : ComponentsEnum.values()) {
// Get the component class information
String className;
// switchComponent has wrong classpath in ComponentsEnum
if (value.name().equals("switchComponent")) {
// Use correct qualified name
className = "net.bootsfaces.component.switchComponent.Switch";
} else {
// Otherwise, use specified value
className = value.classname();
}
// See if this is an internal reference
if (className.contains("Internal")) {
LOGGER.log(Level.INFO, "Init Bootsfaces: Skipping internal component: " + className);
} else {
LOGGER.log(Level.INFO, "Init Bootsfaces: Processing component: " + className);
try {
// See if we can instantiate the class
Class componentClass = Class.forName(className);
Class<UIComponentBase> baseClass = componentClass.asSubclass(UIComponentBase.class);
UIComponentBase component = baseClass.newInstance();
String rendererFamily = component.getFamily();
String rendererType = component.getRendererType();
// Determine the renderer class name
String simpleName = componentClass.getSimpleName();
String rendererClassName;
switch (simpleName) {
case "NavCommandLink":
// Shares same renderer with NavLink
rendererClassName = "net.bootsfaces.component.navLink.NavLinkRenderer";
break;
default:
// We have to guess at the name of the renderer
rendererClassName = className + "Renderer";
}
// Look up the renderer
Class rendererSuperclass = Class.forName(rendererClassName);
Class<Renderer> rendererClass = rendererSuperclass.asSubclass(Renderer.class);
Renderer renderer = rendererClass.newInstance();
LOGGER.log(Level.INFO, "Init Bootsfaces: Registering renderer: " + rendererFamily + "/" + rendererType);
// ****** THIS IS THE IMPORTANT CALL TO REGISTER THE RENDERER *********
addRenderer(rendererFamily, rendererType, renderer);
} catch (Throwable e) {
LOGGER.log(Level.WARNING, "Init Bootsfaces: Unable to register renderer for component: " + className, e);
}
}
}
}
public void addRenderer(String family, String rendererType, Renderer renderer) {
getDefaultRenderKit().addRenderer(family, rendererType, renderer);
} |
|
@BalusC @tandraschko @cagataycivici Some of the users of BootsFaces have observed a very strange phenomenon. According to the analysis of @jimmc929 (see the ticket history above), some application servers don't recognize the JSF annotations reliably. In particular, Have you seen this problem before? |
|
Known problem - mostly in older versions. Therefore we still stick with xml config :/ But NOTE: in PF we still support JSF 2.0 |
|
Thanks for your quick reply! I agree with you, this should be fixed if Glassfish wants to be the reference implementation of JSF. But you know the old saying: If the mountain won't come to Muhammad, Muhammad must go to the mountain. |
stephanrauh
added
confirmed
issue with other JSF fwk
and removed
verifying issue
labels
|
Hello friend , I had this problem with GlassFish 4.2.0 , but downloaded new 5.0 and added this parameter to glassfish-web.xml : < parameter-encoding default-charset="UTF-8" > |
|
@gaidai could you please escape the XML of the parameter? I think it has been automatically removed. |
|
And second param I added to web.xml : < context-param > |
|
Tengo el mismo problema. Proyecto Original
Copia de Proyecto
web.xml
shiro.ini Ejecución Netbeans 8.2 OSX El Capitan |
|
Supongo que es una falla de Glassfish. La llamada "reference implementation" de JavaEE frecuentemente tiene dificultades con anotaciones. ¿Puedes usar un otro servidor de aplicaciones? Si no puedes user un otro servidor en producción, ¿puedes desplegar tu aplicación en un otro servidor como prueba de compatibilidad? |
|
Use Ahora en Payara
|
|
Hello! I have the same issue even with the nightly version of Glassfish 5.0.1. It seems like that this hasn't been fixed yet there. On local deployment, I had to redeploy 2-3 times until it worked. On a remote server, this never worked even with trying different steps. Thanks to @jimmc929 I was able to use his workaround to make Bootsfaces always be rendered at every deploy. I've changed it up a little to fit my needs as I didn't have a function getDefaultRenderKit(). If anybody needs them here's the extra snippet: private RenderKit defaultRenderKit = getDefaultRenderKit();
public RenderKit getDefaultRenderKit() {
RenderKitFactory renderKitFactory = (RenderKitFactory) FactoryFinder.getFactory(FactoryFinder.RENDER_KIT_FACTORY);
FacesContext facesContext = FacesContext.getCurrentInstance();
return renderKitFactory.getRenderKit(facesContext, RenderKitFactory.HTML_BASIC_RENDER_KIT);
}
public void addRenderer(String family, String rendererType, Renderer renderer) {
defaultRenderKit.addRenderer(family, rendererType, renderer);
} |
|
@jimmc929 @tg47 @TheTimeWalker I've compiled your hints to an article: https://www.beyondjava.net/running-bootsfaces-on-glassfish-or-payara I don't know your real names, so I used your GitHub account names for the kudos section. If there's anything to improve, just drop me a message. |
|
It says: Forbidden |
|
@nando2301 Oops, sorry - I've changed the URL pattern on my server. Try again. The correct URL is https://www.beyondjava.net/running-bootsfaces-on-glassfish-or-payara |
|
@stephanrauh I just had to use your blog article to solve this same issue on Payara 5.184 (the latest release as of this writing). However, I noted that your class wrapper you put around the function that was shown above needs a default constructor that calls the private method otherwise the private method never gets called. Here is the top of my implemented class. I also switched out the JSF @ ManagedBean annotation for the CDI @ Named annotation and used the OMNIFaces @ Eager annotation as well. Lastly, I defined the LOGGER variable within the class which was missing also. @Named
@Eager
@ApplicationScoped
public class InitBootsfacesBean {
private static final Logger LOGGER = Logger.getLogger("com.arcadis");
public InitBootsfacesBean() {
initializeBootsfacesRenderers();
}
/**
* Register the Bootsfaces renderers
*/
private void initializeBootsfacesRenderers() {
... |
This is a follow-up to issue #636 submitted by tg47. Unfortunately, this issue continues to plague us. I work with Tom and I have a separate Bootsfaces project completely independent of his that behaves the same way. We are using Payara 4.1.1.171 (build 137). I am using Bootsfaces 1.0.2. I am working on a completely separate set of workstations than Tom (different machine, different O/S, etc.) and am seeing the same behavior. Here is what happens:
I deploy an EAR to Payara. In 80% of the cases everything works great. However, in about 20% of the cases, the Bootsfaces components do not render. In this situation, non-Bootsfaces components on the page do render, such as h:outputLabel, h:form, etc.
I can solve this problem in one of the following ways:
(Note that there are no other applications running in the Payara instance- just the one under test.)
In 100% of the cases, one of these steps will fix the problem. For this reason, I am inclined to rule out issues in the build process. If the same EAR can be made to work by restarting the container, etc., it does not seem all that likely that the problem is in the way the EAR is built. (Tom had also observed differences in how an EAR with Bootsfaces behaves depending on which server it is deployed to. All servers are running the same version of Payara, so again this would seem to point away from build issues.)
I have downloaded the Bootsfaces sources and have been debugging the application. (Our application is quite simple.) Here is what I am seeing:
The AddResourcesListener methods processEvent() and isListenerForSource() methods are being called. The seems to indicate that Faces is aware of the Bootsfaces component library. The processEvent() method successfully calls addCSS(), addJavascript(), and addMetaTags(). There do not seem to be any exceptions thrown in these methods.
I then put breakpoints in the ContainerRenderer (for b:container, which wraps the JSF page) and the encodeBegin() and encodeEnd() methods are never called. I also tried breakpoints in various other renderers, such as b:panel, etc., but none are ever called. It seems that Faces is skipping rendering the Bootsfaces components entirely in the Render Response Phase.
It "feels" to me like some sort of race condition is occurring during deployment. Once the EAR deploys successfully, it runs properly forever. But in (roughly) 20% of the cases, something seems to go wrong in deployment, and from that point on, Faces does not seem to call any of the Bootsfaces renderers during Render Response Phase.
Can you think of any possible cause for this? I am not an expert in the internals of Faces, so I don't know where to put a breakpoint to see where the top-level Faces code should be calling into the Bootsfaces renderers. I can see that the Render Response Phase is proceeding normally, and the non-Bootsfaces components are being rendered. I thought that the AddResourcesListener would probably not be called in this situation, but it is. So Faces seems to know about the existence of Bootsfaces. (I can see that AddResourcesListener is specified as a SystemEventListener in the faces-config.xml file.) I'm more than willing to continue to debug the situation if you can offer any suggestions as to where to look. I've noticed a few other posts alluding to the same problem, so I don't think this is an isolated instance (though it might not be very common). We think Bootsfaces is terrific and would like to continue using it, but this issue makes each deployment a bit of a guessing game. Any advice would be appreciated, thanks!
P.S. I haven't described the application in detail because I don't really think the application code is all that relevant. I have seen this behavior with just a simple JSF page with b:container, etc. There are no other complicated libraries included (e.g., my project does not use Shiro, etc.). I could probably create a simple demo application if needed, but then in ~ 80% of the cases it will work perfectly, so I'm not sure how helpful that would be. The Payara server log shows "Application running on Bootsfaces 1.0.2" and there are no errors or exceptions. In other words, we've tried to look for the obvious stuff first! :)
P.S.S. I notice that Bootsfaces uses a variety of external resources. I am not sure if these resources are retrieved asynchronously, but is it possible that if one of these resources is not retrieved quickly enough, that Bootsfaces gets "stuck" in some way and is unable to render components? Whatever is happening, the actual component renderers are not being called during the Render Response. Just a thought...
The text was updated successfully, but these errors were encountered: