Our application is having issue with rendering time on various part. We have been able to pin point the performance issue with a profiler (YourKit Java Profiler) within the JSF restoreView phase (lifecycle). Since, we use a lot of components in some pages the rendering of the tree must be the source of the problem. Some question on stackoverflow looks pretty much like what we are dealing. Also, we can see the same slow speed in dev and production.
Some specs:
MyFaces 2.1.7
javax.el 2.1.0
Profiler (CTRL+SCROLL to see details):
We are trying to find solutions. So far, we came up with those:
Use less composition/components (which is not that great, because we liked to make generic component).
We could also go into JSF stateless mode.
Find the actual problem with JSF (IN DEEP).
Recently, we found out that some JUEL library (expression language) could greatly increase the rendering time.
I've been dealing with making JUEL works with Spring 3 (with OSGI). Here's the spec:
JUEL 2.1.3.1 bundle (note: this bundle use a different version of javax.el than the one I use in my application will that cause clash?)
I have found another maven repo which only does Juel Implementation and a more recent version.
Update:
Found a solution for javax.el clashing, since there was a lot of problems in the juel-api (because it's export his own javax.el) I modified the manifest with that line Fragment-Host: javax.el to eliminate it.
Is there a configuration/set up to enable better performance?
Or, how to you actually configure JUEL with MyFaces and Spring?
I would say that the problem is caused by Spring Web Flow. I remember this issue SWF-1540. First check if you are using the right version (2.4.0.M1 or upper). Note personally I have not tested if that configuration has a performance issue, but I can say that MyFaces 2.1.7 an upper versions does not have any issues. It is known that some EL versions has perf issues, so try with juel or with apache EL (jasper-el, bundled with Tomcat).
As a personal opinion, watch out for Spring proxies, it is known that in some cases, when the pages are very big and complex, the proxies has a significant impact over performance. The suggested solution is use Apache OpenWebbeans, which is a very fast CDI implementation, optimized for those cases when you have a lot of beans interconnected.
You can check this article too "Understanding JSF 2 and Wicket: Performance Comparison" for tips about MyFaces performance.
You have to try by yourself what will work for your case, but I hope with these advices you can focus better your search.
Related
I noticed that there are only a few camel extensions available to use in native mode. I am wondering if it's still possible to use the other camel components if you don't compile to native? And if, is it usefull to go that way, or should we for example stick to spring boot?
Note that all Camel extensions might not need a Quarkus one. Basically, a Quarkus extension is needed if we need to tune the Camel extension for GraalVM (add reflection declarations for instance). The interesting thing is that you can even do the work manually to make your Camel extension work in GraalVM mode and then report back so that we create a proper extension for all future use.
In JVM mode, all Camel extensions should work flawlessly. If you encounter an issue, please open a GitHub issue and we will take a look at it.
About if using Quarkus in JVM mode is worth it, I'm obviously partial but I think the Quarkus approach is beneficial even in JVM mode. You still have some of the benefits of better boot time and reduced memory usage. Obviously, depending on your application, they might not be important to you.
The current system I am working on uses Tomcat 7.0 and Spring 3.1 the system is a collection of web apps that all have the same classpath in WEB-INF\lib, I am thinking of adding spring 3.1 to my tomcat\lib so that all the web apps have access to it. Is this safe to do with Spring 3.1?
Safe to add Spring 3.1 to the Tomcat main lib directory? Quite possibly. Good idea? Probably not; as the system administrator you'd be taking on the responsibility for ensuring that all the webapps can use that exact version of Spring (including all the issues that can crop up when you update things) because the webapps would not be able to override it to anything else. (To be fair, they could load classes from elsewhere that weren't in the standard system version you're proposing, but that's likely to be an extremely bad idea as there would be problems with warring versions of the same library. That's a very confusing situation to be in; avoid if at all possible!)
As a general rule I only put very basic shared libraries like JDBC drivers in tomcat/lib. Sharing other libraries will often lead to classloader issues in tomcat. Unfortunately, I don't know the publish date of it, but you might find this article http://www.mulesoft.com/tomcat-classpath useful.
I know the title may seem like apples & oranges, but hear me out... :)
I'm building the architecture of an MVC app and considering what to use for the core of the controller / services. This stack will also serve as a RESTful API which will be equally as important as the UI.
I'm narrowing down my stack to be built with either Grails or JAX-RS (at this point I've ruled out other options and am not super interested in expanding this list). Either way I'll be using Groovy, and my model and views will be virtually unaffected by this choice, so that further levels some of the differences between the two. Here are the pros/cons that I've been pondering and was wondering if anyone had any other inputs or caveat experiences.
Grails
I am not going to use a ton of the built-in Grails features (GSP/SiteMesh, Hibernate, nearly all plugins), so I'm concerned that Grails might be a bit heavy for my purposes
I'm concerned that I won't have enough control over my ability to handle the REST API since it is very view-centric
I've seen inconsistencies in the quality of plugins to the point where I'm not sure I consider them much of a 'pro'
I love the convention-over-configuration & edit-and-refresh, to the point where I'd probably want to wire up something similar if I go with JAX-RS
I like the grails command line for everything it streamlines, but I'm concerned that it might get in my way since I'm not using as much of the stack
I like the scaffolding but since I'm not using Hibernate or GSP/SiteMesh it might not mesh well
JAX-RS
JAX-RS is made for REST. This will make my RESTful API really a snap to implement as I have complete control
Groovy is an important part of what makes Grails shine, so I'll benefit from that even in JAX-RS
I love how JAX-RS doesn't automatically pull in a bunch of other things so I can have more control of what components are in/out
unfortunately since it doesn't pull in everything else anything that I end up needing will require more work, whereas Grails might have a plugin
the grails command line and scaffolding will be missed; perhaps Maven can fill some gaps
It seems like the capabilities of each for creating actions and routing are pretty similar (although the implementation styles are different). In fact there are other SO questions wish touch upon this so I'm not too concerned.
I wrote a small REST service prototype in several frameworks last year (namely Grails, Play!, Spring MVC, Jersey, Restlet). My feeling about Grails in this concern was that although Grails supports REST style architecture, it isn't really made for it. I don't want to get religious here, so if you only want to map resources to URLs and HTTP verbs your fine, but if you want to dig deeper into REST with tight control over return codes, location headers, etc. you might still be able to do it with Grails, but it is probably better supported in a pure REST framework.
Grails also comes with a lot of dependencies, which might not be a problem if you're starting on a green field, but can cause problems when you have to integrate it with existing legacy components or frameworks.
From the two used REST frameworks, I liked Jersey more, as it just worked in my case and the documentation was good (although a bit focused on Maven and Netbeans).
Yeah, it does seem heavy to build on a MVC framework when you're not going to use the model or the view. While the autowiring and simplified configuration is super nice, Grails would still be providing a lot of extra stuff that you don't need.
I'd personally take the lighter approach and leave Grails out, using any standalone libraries or writing custom code which provide the features that you do want. There's a number of container projects listed on the Groovy site, perhaps Spring or one of the alternatives would add some value to your architecture.
I am just starting to learn about spring and was looking at the difference between Spring 3.0 and Spring 2.5.
Initially i was following this tutorial http://static.springsource.org/docs/Spring-MVC-step-by-step/index.html which is a step by step guide to developing a Spring MVC application. It is based on Spring 2.5 and i notice there are quite a few differences with Spring 3.0. I tried to find the equivalent tutorial that is based on 3.0 but couldnt find it.
The difference i notice with 3.0 is that there is a lot of use of annotations and a lot of things is done for you in the background. I am sure this is a good thing but i am wondering for the purpose of learning the framework should i continue with 2.5 so that i can understand what goes on behind the scenes before i use spring 3.0?
Please also if you can recommend a spring book that is suitable for a beginner i would appreciate it.
Thanks
I'd recommend to always use the latest version of a framework. Especially if you're starting on a new project. There are always (well usually) tons of improvements, and simplifications, and migrating to the latest version later may be a pain.
Spring has a great user manual (see http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/), and IMHO a book doesn't have an added value in this case. I found the Spring user manual always easy to read and understand, so don't get intimidated. I think this is definitely the best starting for beginners as well. You don't have to read it all. Only the sections of interest!
Note that Spring 3.x contains many other improvements such as SpEL (Spring Expression Language), improved web support (you already saw that), REST support, and more.
... should i continue with 2.5 so that i can understand what goes on behind the scenes before i use spring 3.0?
That's really up to you to decide, but if you are going down the Spring 3.x annotation-based route, it is not clear that you >>need<< to understand what is happening behind the scenes. Especially for run-of-the-mill applications.
I was not aware of the purchase of Spring by VMware. Do you think this might affect the open source aspect of Spring in that it might not be open source anymore?
First, the SpringFramework guys are thoroughly committed to open source (from what I can see). So a change would probably entail lots of developers leaving.
Second, most of the people who use Spring do so because it is open source, so a change would risk a major migration of (paying) customers away.
Third, turning Spring into a closed source product would be a politically awful move for VMware, and would likely have fallout for other VMware product lines.
Finally, and most importantly for people committed to using Spring: there is no way that the VMware could legally "undo" the open sourcing of current Spring releases. The best they could do would be say that Spring 4.0 etc was closed source. Anyone who wanted to would be free to continue distributing and using SpringFramework 1.0.x, 2.0.x, 2.5.x, 3.0.x and all associated open sourced technologies. And anyone would be free to create a "fork" of any of them to continue Spring open source development. The only possible issue would be the use of trademarks, and that is easily worked around.
Add that all up, and (IMO) there is nothing to worry about.
"Spring in Action", "Pro Spring", and "Spring Recipes" are the three that I'd recommend to anyone.
If you've never used Spring, I'd say that learning either one will suit your purposes. The majority of Spring 2.5 carries over to 3.0, so it's not wasted.
The books and tutorials haven't kept up with Spring 3.0. Another change between versions was the purchase of Spring by VMWare. They've separated paid support from open source, so it's hard to tell what the future will be for non-paying customers.
Spring roo is new framework and I found it very interesting. I have been working on web application for last 3-4 years and Always found JSPs are hard to maintain across teams if everyone is not disciplined enough about separation of markup and serverside logic. I have used JackBe/BackBase in last projects and I enjoyed xml templates working as views. This was much better than JSPs. But I couldnt automate webtests through selenium for backbase.
I would be surely using Spring MVC (-view), Hibernate on the backend. I found Wicket as good alternative. Have you used wicket along with Spring and what was your experience?
First, Spring Roo is a code generator tool (similar to Grails commands system):
(source: springsource.com)
Second, Spring Roo applications currently use Spring Web Flow for the view and Spring for the glue.
So, while you can compare (Spring Web Flow + Spring) and (Wicket + Spring), the later combo doesn't offer anything comparable to Roo out of the box (maybe AppFuse or AppFuse Light but you didn't mention them and they are third-party projects).
In other words, I don't think that "Spring Roo vs (Wicket and Spring)" makes sense.
Our current project uses Spring and Wicket, we have always used Spring but switched to Wicket a year ago. Few advices:
Get the "Wicket in Action" book.
The user mailing list is very helpful.
Make sure you understand Wicket's programming model especially the session serialization related stuff (the book does not help enough in this area IMHO).
Wicket is good at building stateful pages, it requires more work to build stateless pages.
There are some good UI widgets available like inmethod DataGrid.
It's easy to inject your Spring beans in your pages or components.
Spring Roo is still in beta (1.0 M2), so it may be a little early.
We also considered Tapestry 5 but we thought it was a bit young a year ago.
Spring Roo 1.0.0 (GA) has now been released, complete with around 100 pages of documentation.
If you're wondering about what Roo is and why use it, I recommend you take a read of the introductory chapter of the reference guide. It covers this and more.
#Antony, GWT support is a major priority for Roo and something I am currently working on. Expect to see some interesting integration in the very near future.
I was at the SpringOne conference in Amsterdam earlier this year when they announced Roo. My impression (and that of my colleague who was there) was that Roo was good if you were generating a web-based CRUD application every few weeks - they pitched it as the pure Java version of Grails (which is RoR for Java).
Didn't look interesting for anyone else - but that's just an opinion.
I've seen a demo of Roo a few months ago. It looks a lot like Grails (another spring technology), except that instead of creating artifacts for the Groovy language, you create them for Java.
Still it enforces good practice and makes you apply the MVC pattern in a clean way.
Personally, the demo didn't make me change my preferred toolkit (Grails), but that's because I can achieve faster results with Groovy (parsing xml for example is much more "painful" in Java than in Groovy). Also, with Grails I can see the changes I make instantly without having to recompile my entire project and relaunch the application each time I want to see the results.
Last but not least, in Grails you have tons of plugins to make fancy Ajax websites (ZK for example, if you want to avoid Javascript, but there are plugins for GWT, Yahoo, Dojo, etc...).
So, if you don't want to learn Groovy (which is not too difficult if you already know Java), Roo is the way to go to build clean web projects with all the power of Hibernate and Spring.
I hope this helps...
Why use Roo when one can build something w/ GWT and end up w/ a far richer better outcome and without the constraints of Roo and its architecture. Spring Web Flow is yesterdays technology.
It completely depends on what your requirements are. If it's a small site then Component Oriented frameworks like GWT or Wicket are a must as they make things really easy.
How soon with Roo support GWT? I think that the use of GWT by Roo makes it a huge win for GWT and Roo!
Roo and GWT are available today in pre-release form. In my opinion, definitely not ready for prime time.