Consider the scenario of a typical webapp with JSFs on the front and EJB 3, with Hibernate as JPA provider, talking to backend database such as mysql, etc. The main user actions are login and mostly CRUD operations (minus any D(elete) operations). And the App Server is GlassFish of course.
Given this scenario, how and where all would one go about providing caching to improve performance? From what I have googled, I have seen that hibernate provides some sort of caching through different cache providers. Is there any sort of caching that can be provided for the jsf pages? How about session beans or entity beans on the ejb side of things?
Also, I just read about memcached and was wondering if this was something to consider?
This article on second level caching by Jacob Orshalick is worth a read.
Seam has a JSF tag <s:cache> that allows page-fragment caching. The caching chapter of the Seam Docs is also worth reading.
Related
I am working on JSF application. I want to cache some database table on periodic basis. I heard EHCache does it, but I only see its use in Hibernate. Is it possible to use EHCache in JSF application or is there some alternative for that in JSF?
if you want use EHCache in front end part you should write cache handler with
net.sf.ehcache.CacheManager or primefaces support now ehcache, if application is big, prefer to have
cache handler service which put/get/check objects from the cache.
It is your responsibility to integrate with a caching layer if none of the frameworks you use provide such an integration. You will usually do this at the service layer that computes your view objects from your stored domain objects.
Ehcache supports different caching patterns. And here again, picking the one that fits your use case is your responsibility.
I have looked at several JavaEE 6 login tutorials using servlet 3.0 and JSFtechnology. Often it shows a request scoped credentials bean and a user manager session bean. Most do not provide packaging info or for simplicity sake create everything in one package. I have been struggling with the packaging between the web tier and the business logic. I do not know if backing bean, controller, manager, and facade are all talking about the same thing or not. A short answer could tell me how to package a user manager session bean and the credentials bean, but a more appreciated answer would help me navigate the web tier and the business logic. Thanks in advance.
For packaging I like to break first by functionality (like core, gui) and then by business unit level.
for e.g
com.comp.db.beans // place your database beans here (if using any orm )
com.comp.web.ui.controller // place your controller, managedbeans here, this can be again broken into functionality wise like login, processing e.t.c.
com.comp.web.ui.beans //you place your vo here
In order to start packaging you have to first write down the different functionality of your system.
Then break them into business unit wise
Then break those into more finer level, to distinguish if functionality is going to be very specific to ui, or does it belong to core.
I have a working knowledge of Struts2 and Spring. I want to develop an application that manages information for multiple companies. I am totally confused about what technologies are best for my application. For instance: Struts2, and Hibernate MVC with Spring.
Can somebody help me select appropriate technologies?
Here is a quick breakdown of a J2EE stack you can use:
Use Struts2 for your controller layer
Use Hibernate for your data abstraction layer. Create service interfaces for your DAO. The interfaces will allow you to use some type of RMI for services later if desired, meaning those services can run on different machines than your web app. Have concrete classes implement those interfaces. The classes will contain business logic and validation of data, and will wrap the Hibernate session. The Hibernate session is used to read/write to/from the database. Use Hibernate annotations to expedite the implementation of Hibernate beans.
Use Spring for instantiating your service classes and Struts2 actions. Configure Spring to inject service instances into your Struts2 actions. This is called dependency injection. Reference interfaces, not classes in your Struts2 action's setter methods for the DI.
Use the Struts2 tag library or JSTL in your JSP, which will be your view layer.
Use Maven for your builds and deploys.
Run Apache with mod_jk, and use Tomcat as your servlet container. mod_jk runs w/ the Apache process, and passes requests to the Tomcat servlet container, which lives in the JVM.
If your application requires search capabilities, use SOLR, a REST service built on top of Lucene.
Instead of using Struts2, you could also take a look at Apache Wicket.
I had the same question few days back and following are the links I used to make a decision - I settled for Spring MVC. Also check out Spring ROO if you are starting afresh.
Choosing the right web framework
Comparing web frameworks
What Web Application Framework?
Ultimately choice will be based on your needs - but above links discuss what parameters you should consider before choosing one.
Hope that helps.
Agree with #Simian, and add some comments and reasons.
From a technological perspective, you should use any framework that utilize modern and mature technologies, such as Struts 2, Spring MVC, Hibernate, JSF, and etc.
However, from a business perspective, you should take more emphasis on the business model that your project consist of, and the demand for the framework is easy and rapid to implement, as well as robust and easy to maintain.
Therefore, as you are familiar with Struts 2, and Spring, I recommend:
1, Use Struts 2 as the MVC framework of your project, but use AJAX if required. You can also develop your interceptors to fulfill some common requirements of your project.
(Or, if you have time, you can learn Spring MVC as it works well with Spring framework, and has better support of AJAX and RESTful. JSF is not recommended, not because it isn't a superb framework, but it use a set of complete different concepts comparing to Struts 2 and Spring MVC, and it is difficult for an unskilled person to debug )
2, Just use Spring jdbcTemplate as your data layer, use DAO pattern to decouple.
(Or , you can learn Hibernate or JPA as your ORM framework, if you have time.)
3, Use Spring IoC to manage your objects and integration with Struts 2 and Hibernate, and manage transactions with Spring's annotations.
I've been doing it like this lately and find it so much better than XML hell(Spring security) or Glassfish security(because I don't need to have groups or set the tables up a certain way). Is this an ok way to secure Java EE applications? Thanks!
A homegrown Filter is perfectly doable when properly written, but it's less maintainable/reuseable because it's tight coupled to the webapplication in question. Java EE container managed security and Spring Security offers an API which is the same and reuseable for every webapplication. This may end up to be easier for developers/maintainers who are working on multiple different projects and wanted to implement/maintain the same. While relatively easy to implement, a homegrown Filter simply violates the DRY.
By the way, I wouldn't recommend using a PhaseListener for this since this hooks on JSF requests only, not on other requests like static CSS/JS/HTML files and "plain" JSP files.
Has anyone had success building a SEAM Application without using Stateful session beans? There is some confusion on a new project in which I think several stakeholders have essentially 'banned' stateful session beans... but some development is being done in SEAM.
Most of the literature on SEAM encourages the use of Stateful Session Beans. Thoughts?
You can absolutely use Seam without stateful session beans. You don't need any type of EJB at all, if you don't want them. Seam can be deployed on a variety of app servers, including Tomcat which doesn't support the use of EJBs. Seam has the ability to mimic a lot of the functionality that EJBs provide -- session scope, transactions, etc. -- without actually using an EJB.
Using Seam with Tomcat, for example, you can have a very robust application without EJBs that is lightweight, but acts in a manner similar to an application deployed on JBoss or Websphere that does make use of EJBs.