javaee-samples
Minor fixes to close json resources, prevent malformed URLs, and correct index.xhtml values
Yes, so to answer the question on usecases, I am running the samples with both the june beta of liberty as well as glassfish. I can't get the samples that use the faces api to work on glassfish, but in liberty the base URL has an ending slash, so it conflicts with the addition of '/faces'. I thought the best way to get around this without causing conflict would be to replace '//faces' with '/faces' to avoid double slashes.
Now, on the updated assertions, I also could not get these samples to run on glassfish, so I wasn't able to crosscheck against liberty. Liberty failed the tests on those assertions, but returned the new strings that I added. They seem slightly more descriptive than the old assertions, so I thought there might've been an update somewhere.
Can you test these against WildFly and see how they behave? If they are failing against GlassFish then @m-reza-rahman can help you.
I thought the best way to get around this without causing conflict would be to replace '//faces' with '/faces' to avoid double slashes.
I didn't look at the exact usage of /faces, but if it's for mapping purposes a general advice is to use .xhtml to .xhtml mapping. This will be the default in JSF 2.3 anyway, and for 2.2 and earlier can be realized with a simple servlet mapping.
Okay, so I ran the tests against Wildfly this morning. The replacement to avoid double slashes worked fine, but the assertions that I updated are different than they were on liberty. I'm not sure why the returned values for the assertions are different or which one of them is technically correct, so if you have any input there it would be greatly appreciated.
@rbrinkster are you saying that the assertions for WildFly and Liberty Profile are different?
Yes, they are different. Apparently the spec does not require the returned messages to be identical. The only thing that must be identical is the returned code from my understanding.
@rbrinkster have you filed the spec issue? I'd like to close this request after that.
Hi Arun, my apologies for the delay in getting back to you. I have communicated this issue to the IBM expert group reps responsible for Bean Validation and JSF. They will be taking care of opening up a spec issue if needed.
Lets clarify that this is indeed the issue, otherwise this change may not be valid.