related to a previous un-answered question of myself: how can i find the code that will be executed when i use
<replace-with class="xxxxxx.xxxxxx.BeanValidatorFactory">
<when-type-is class="javax.validation.ValidatorFactory" />
</replace-with>
I suspect it may be causing an unexpected behaviour when the ValidatorFactory is used somewhere else but the client and i wonder if having an eye on the code can point me to a workaround/solution.
Thx!
Related
I have a project where OmniFaces 2.6.8 is used. In this project I have some facelets tag files, which use OmniFaces' <o:tagAttribute>. For some of my tagfiles I noticed strange behavior, which means, the <o:tagAttribute> seems not to be working and I get
IllegalStateException: Duplicate component ID 'myForm:outer' found in view.
as a result, because the id-attribute of my outer tag is not cleared and thus reused in the inner tag (just as demonstrated in OmniFaces' show-case).
I could reproduce the problem with two very simple tag-files. Here is how I use those tag-files first:
<h:form id="myForm">
<my:outer id="outer">
<my:inner />
</my:outer>
</h:form>
And here is the complete code of the tag-files.
outer.xhtml:
<ui:composition xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:o="http://omnifaces.org/ui">
<o:tagAttribute name="id" />
<h:panelGroup id="#{id}">
<ui:insert/>
</h:panelGroup>
</ui:composition>
inner.xhtml:
<ui:composition xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:o="http://omnifaces.org/ui">
<o:tagAttribute name="id" />
<h:inputText id="#{id}">
<ui:insert/>
</h:inputText>
</ui:composition>
I noticed, that the problem does not arise, as soon as I change inner.xhtml to use <h:outputText> instead of <h:inputText>. It also disappears, when I add a value-attribute to the <h:inputText>.
Is this a bug in OmniFaces, or am I doing something wrong?
(Update: I created an issue in the OmniFaces bugtracker.)
My environment
OmniFaces 2.6.8
Mojarra 2.2.15
Wildfly 10.1.0.Final
This was a bug in OmniFaces 2.6.8, which was fixed (but not mentioned in the changelog) in OmniFaces 2.6.9. Exchanging the dependency version of OmniFaces is enough to solve the described problem.
Update: Note, that there is also a related issue, which was fixed in 2.7.1.
I've just migrated a MVC3 project to a 4.
I also installed the newest update of ELMAH.
I do have an issue with unhandled exceptions.
In my web.config I have this:
<customErrors mode="On" defaultRedirect="/Error/Error" redirectMode="ResponseRedirect">
<error statusCode="404" redirect="/Error/NotFound" />
</customErrors>
When I get an unhandled exception, Elmah logs it, no problem there, but it doesnt send me to the Error/Error view. It also doesn't do the 'ResponseRedirect'
What it does instead is keep the URL as it was, and it shows me the Error.aspx view from the Shared folder.
How do I change the settings somewhere, that the customErrors won't be ignored?
If you are seeing the Error.aspx page then definitely HandleError filter is playing behind it. Go to Global.asax.cs and check HandleErrorAttribute is not added in the RegisterGlobalFilters method.
Also make sure you haven't overridden the OnException method of the controller and doing something manually yourself.
I have included gwt-html5-geolocation into my GWT project and was disappointed to find that it doubled up on my number of permutations compiled. Apparently if the browser does not support geolocation API then it falls back to use gears to find out your location. Is there a way to NOT compile a permutation for gears similar to the way you can tell GWT to only compile certain browser permutations? (the geolocation stuff is very much a nice-to-have and frankly if the client is running an old browser then I am happy not to get their location)
Thanks
Looking at Html5Geolocation.gwt.xml, you could add
<inherits name="com.google.code.gwt.geolocation.Html5Geolocation" />
<set-property name="geolocation.api" value="html5" />
which would completely disable the gears property value.
I'm trying to get some automated UI testing going on a GWT application and I'm having trouble finding a way to track UI elements.
For example, I have the following:
<g:Button text="Submit" ui:field="submitButton" enabled="true" />
which generates:
<button class="gwt-Button" type="button">Submit</button>
Its a compiler error to set both ui:field and id (id is considered deprecated anyway) so the problem is that I have no easy way to select my submit button using something like selenium.
Is anyone aware of a way I can map the
ui:field="sumbitButton"
to the generated HTML?
After further investigation I've discovered that you can enable debugIds which are ment for testing purposes. If you add:
<inherits name="com.google.gwt.user.Debug"/>
to your *.gwt.xml file you can then set debugId on your ui elements as such:
<g:Button text="Submit" ui:field="submitButton" enabled="true" debugId="submitButton"/>
and also in the codebehind by using the ensure debug id method
submitButton.ensureDebugId("submitButton");
Here is my form:
<form action="j_security_check">
<h:panelGrid columns="2" bgcolor="#eff5fa" cellspacing="5" frame="box" styleClass="center">
<h:outputLabel value="User ID:"/>
<h:inputText id="j_username" tabindex="1" />
<h:outputLabel value="Password:"/>
<h:inputSecret id="j_password"/>
<h:outputLabel value=""/>
<h:commandButton id="login" value="Login"/>
</h:panelGrid>
</form>
It work fine with Glassfish 3.0.1, but since Glassfish 3.1 b2 it shows this warning as a FacesMessage in the JSF page:
The form component needs to have a UIForm in its ancestry. Suggestion: enclose the necessary components within <h:form>
If I change the <form action="j_security_check"> to <h:form>, it does not fix it, I have to place the <h:form> inside the <h:panelGrid>.
This is just a Warning not an Error. Warnings are usually there to inform the developer about unforeseen situations/conditions which might not immediately cause technical errors/problems. Anything may just work flawlessly, but the behaviour/results may probably not be as the developer intented. A newbie developer may for example accidently have used <form> instead of <h:form>. Warnings like this are then helpful.
In your particular case, you are simply forced to use <form> because of the need to submit to a non-JSF service. You as a more experienced developer know that it's legitimately valid. You can just ignore this warning. This warning will only appear when javax.faces.PROJECT_STAGE is set to Development anyway and not appear when it is set to Production.
However, that it still displays the warning when there's another component like panelgrid in between the form and its input children, is a bug to me. I'd report it to the Mojarra guys. It look like as if it is checking the immediate parent only and not all of the parents. Update: it has been fixed as per Mojarra 2.1.3/2.2, see also issue 2147.
This is by the way not Glassfish specific. The newer GF version of course ships with a newer Mojarra version which has those warnings implemented. See also issue 1663.
Related questions:
The form component needs to have a UIForm in its ancestry. Suggestion: enclose the necessary components within <h:form>
This was suggested to me by Oleg from the PrimeFaces forum and works:
<h:form id="login" prependId="false"
onsubmit="document.getElementById('login').action='j_security_check';">
Regards,
Brendan.
It only shows if you are in JSF Development based on your web config.
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
When you change it to Production it wont show anymore
If anyone will find this usefull one day,
i had same error and the problem was that i have primefaces component
<p:something ....
and that component was not inside <h:form> element
I'm using Mojarra 2.1.27 and find out that this is my mistakes. However its just very hard to find what the mistakes was. Hopefully someone from Mojarra could add component id to the warning messages.
Here is what I did to found out the component: (which also posted to https://code.google.com/p/primefaces/issues/detail?id=1586#c48)
I trace it by downloading the Mojarra source code and adding break point to com.sun.faces.context.FacesContextImpl class in method:
public void addMessage(String clientId, FacesMessage message).
when the break point catch, open the Debugging window or call stack window to find out that it was called by class
com.sun.faces.application.view.FormOmittedChecker
in method
private static void addFormOmittedMessage(FacesContext context)
which is previously called by method
public static void check(FacesContext context).
inside the check method there is parameter variable component.
You can get the component id from Watch or variable window and then trace it back to your html page and code.
Its a hard way, but hope you can find the root of the problems. It will be much more simpler if the warning message also display the problematic component id
In my case, this warning message was displayed in p:messages which I've put in dialog to show validation errors, so I've just included severity="error"in p:messages and warning message was gone.