Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New test: JSF #307

Closed
bhauer opened this issue May 23, 2013 · 6 comments

Comments

@bhauer
Copy link
Member

commented May 23, 2013

As suggested at the Google Group, testing JSF should involve:

A) Plain JSF Test

  1. Mojarra
  2. Myfaces

B) JSF + Primefaces

C) JSF + Icefaces

D) JSF + Richfaces

@tasel

This comment has been minimized.

Copy link

commented May 29, 2013

I doubt that a test for JSF would produce any meaningful data. The benchmark is focused on JSON serialization and database access. Both topics are completely beyond the scope of JSF. Being a component based framework, JSF does not return raw JSON, though responses to async requests may contain JSON.

A comparison between JSF implementations and libraries would be very interesting but the benchmarking framework is suited to compare platforms rather than MVC frameworks that are based on the same technological platform. What's the meaning of comparing database access in JSF, GWT and Spring MVC based applications when Hibernate is used in any case?

More sophisticated test methods are required to provide meaningful data for a comparison of JSF implementations and libraries.

@bhauer

This comment has been minimized.

Copy link
Member Author

commented May 29, 2013

@tasel Thanks. The apparent mismatch of intents for JSF and this project is why we left JSF (and GWT) out originally. Nevertheless, I have heard several JSF users ask us to include JSF, hence this issue.

I'm not a JSF developer, so I appreciate you confirming our earlier assumption that as long as we're testing fundamentals, it's quite difficult (and without much value) to shoehorn JSF into our test-cases.

Some frameworks go even further and require specific client behavior--bundling custom JavaScript--making them extremely difficult to test at a component-level as we're doing here. Holistic tests of a complete application would be possible, but that isn't our focus.

I'm going to close this. We'd still accept a JSF implementation of the tests if someone were to create a pull request, but JSF users would probably be dissatisfied with the tests.

@bhauer bhauer closed this May 29, 2013
@luan-cestari

This comment has been minimized.

Copy link

commented Sep 18, 2013

I think I could make a workaround to create such test, but it would have some overhead and it would not be very good for the benchmark. Is it possible to we create a different category of test which use tools like webdriver/selenium to get the metrics of such frameworks? I think people might like this new type.

@bhauer

This comment has been minimized.

Copy link
Member Author

commented Sep 18, 2013

Hi @luan-cestari. I'm not sure I understand what you have in mind, but please feel welcome to contribute a new test type idea to issue #133.

@luan-cestari

This comment has been minimized.

Copy link

commented Sep 19, 2013

Thanks, I will post =)

@codylerum

This comment has been minimized.

Copy link
Contributor

commented Jan 19, 2014

While JSF doesn't fit for the JSON/Plaintext portions of the test the entire EE7 stack does cover all of it.

JAX-RS + JPA for the JSON, Plaintext, Single Query, Multiple Query, Updates tests.

JSF + JPA for the Fortunes test.

#755 is an initial implementation of this. Though we are wanting to wait until Wildfly hits Final before inclusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.