Has anyone successfully implmented a Glassfish 3.1 server with websockets and a rich component interface for JSF like RichFaces, IceFaces, PrimeFaces. And If so what is the easiest method or best way to do this? Primefaces requires Jetty, and I think IceFaces uses JMS.
I'm just trying to find a way to add server push from Glassfish to my view that will display a text stream as it is available in the client. I'd like to do this through a component UI of JSF but if it's possible to circumvent the framework while still being able to use it for it's javascript management and UI utilities that would work too.
GlassFish 3.1 is broken in terms of WebSocket implementation and support a really old version of the protocol. I recommend you try the 3.1.2 version. If you want to be "shielded" from Websocket/Glassfish changes, take a look at the Atmosphere Framework. The framework take care of all those change.
-- Jeanfrancois
why not using IceFaces for that? I do not know what does it use internally, but they have ServerPush. The library that is doing this is called IcePush. IceFaces are integrated with IcePush.
See http://wiki.icefaces.org/display/ICE/Ajax+Push+-+Overview
AFAIK now they are using long polling, but I hope they will switch to web socket as soon as it will be ready for enterprice.
Related
I've been using Struts 1.x for more than 1 year now, and I've been learning about JSF recently. I know both JSF and Struts are different frameworks but I wanted to use Struts as Action framework and JSF as Component framework in my web application. I'm not sure if we can do that, and couldn't find any materials online regarding this.
Suggestions and links are welcome, Thanks in advance
Struts and JSF can be used in a web application, some(or no) changes might be required in the back end but as both the frameworks follow MVC, the "VIEW" tier would be much similar.
As JSF and Struts both have their own advantages, we can use the advantagesof of each combinedly, like ValidationFramework in Struts and JSF components (html components in Struts)
All this I would just only if you have an existing Struts application, can find more detailed information here
though the link talks about older versions, i hope it gives basic information
I have J2EE web application which uses JSF framework. Now I am trying to add chat functionality to my application. The problem that I am facing is
When someone pings me, i should be able to see a chat notification on my jsp page. Which means server should be able to update my page when new chat notification comes. Please tell me how can my jsp page listen to incoming packets.
You should look into push technologies. Many JSF libraries support it directly: icefaces, richfaces and primefaces at least. If you don't want to use any of these you may also check out atmosphere, but this will require some javascript and server side coding.
Could any one throw some light on the following jsf component libraries to be used in Liferay portlet development which supports Inter Portlet Communication (IPC), Ajax Push Support and JSF - Portlet bridge, community support etc., for Primefaces, Richfaces, Icefaces and Myfaces.
--Velu
From my own experience I have to agree with what doc_180 says, among the frameworks you mention ICEFaces is definitely the best choice, but stick to new 2.0+ version as it has many improvements.
A lot can off course also be done by using the same stack as Liferay itself uses in the 6+ version: Struts/MVC-portlet + AlloyUI
ICEFaces works like a charm with liferay. Especially with ajax push support, its a very good choice.
Currently, my web-application is based on the following libraries / frameworks / tools:
Java 1.6
JSF 1.2_07-b03-FCS
Facelets 1.1.14
Richfaces 3.3.2.GA
EL-Functors 1.0.2
Spring 2.5.2
Tomcat server v5.5
Some additional information:
Spring is in charge of managing all the beans used by JSF (org.springframework.web.jsf.DelegatingVariableResolver is defined as the variable-resolver in my faces-config.xml file).
EL-Functors is used as my el-resolver in order to extend the Expression Language.
I've created many custom components, some of them are just Facelets compositions, others are Java-based components (some of them are extending Richfaces components).
I want to try (essentially for curiosity, but if this works well, why not for real?) to migrate my application to JSF 2.0.
Question #1: what are the critical points that I must consider in order to make my application working correctly?
I am talking here about just having a working application, nothing less, nothing more.
I alread know that I will have to review all my custom components, because I will use the new version of Richfaces (4.0), and also see if they work correctly.
Question #2: what will be the first steps to achieve to take advantages of JSF 2.0?
Some ideas I already have are:
Remove EL-Functors and use the Expression Language 2.2;
Let JSF manage the beans, and use the #ManagedBean. Or maybe switch to a CDI library, such as Weld?
Use <f:ajax> instead of <a4j:support>?
Regarding JavaEE6
I know, a good idea would be to completely move to JavaEE6. I'd liked to do so, but for some reasons I just can't do that way. One (bad) reason is that I must stay on Tomcat servers.
However, I can add new third-party libraries in order to have some JavaEE6 features, such as EL 2.2...
So please consider this aspect in your answers.
Regards.
Since Richfaces 4 is still under development you may want to use Richfaces 3.3.3 with JSF 2.0.
Thus you have to use Facelets 1.1.15 as described here http://community.jboss.org/wiki/RichFaces333andJSF20
This implies that switching from a4j:support to f:ajax won't work with your Richfaces based components so I suggest to stick to a a4j:support. This will also keep the migration effort low if you decide to switch to Richfaces 4 as soon as it is available.
Since you already use Spring to manage your JSF-Beans there should be no need to use the DI-Features of JSF2. I'd stick to Spring but consider an update to Spring 3.
Besides this, Weld is definitley worth to take a look at.
HTH
If you plan to stay with Tomcat, then moving to Java EE 6 means you're going to be looking at Tomcat version 7.
But if you want a full-fledged Java EE 6 server then GlassFish 3 or JBoss 6 is a better alternative. Tomcat can be iffy when you try to do certain thing like CDI (Weld) or EJB 3.
Just my two cents worth. Hope it helps...
Just a general question, open for discussion...
I'm very much liking JSF so far, I'm new to it, but I prefer it to Struts. From a professionals standpoint, do you see a strong future for JSF ? Is it worth an investment as a young programmer to learn JSF 2.0 over Struts or another similar framework ? Should I stick to regular JSP ? Is Ajax really simpler through JQuery than JSF ?
I like new technologies and I like what I see so far from JSF but I want to be practical as well, and a lot Google searches turn up some bluntly critical comments about JSF 2.0.
Thoughts ?
Comparing JSF with Struts is like comparing apples with oranges. Struts is a request/action based MVC framework while JSF is a component based MVC framework. Struts is also aged. In the IT you're supposed to keep moving. Generally, a component based MVC framework is seen as a further evolution of a request/action based MVC framework.
JSF is currently already used very widely. It has indeed received a lot of critism before. You can read about most of them in the question What are the main disadvantages of JSF 2.0? The strength of JSF is mainly being a Java EE maintained standard and the availability of relatively a lot of 3rd party component libraries (PrimeFaces, RichFaces, IceFaces, OpenFaces, Tomahawk, etc). With JSF, it's very easy to develop CRUD applications and web forms with nice look'n'feel quickly.
However when it goes into the complex, JSF may cause some unforeseen surprises. Although the JSF specification and reference implementation (Mojarra) is pretty mature since the latest 1.2 builds, you may encounter some very specific behavioral problems which goes against your intuition. Some are just "by design" and can only be understood when you understand in detail how JSF works under the covers which in turn often boils down to the stateless nature of the HTTP protocol. JSF abstracts it in essence "too much" away that you don't see it anymore. Some are just bugs in the 3rd party component libraries used, but that's thus not strictly JSF-implementation-specific. Bug/issue handling is however pretty good in most of the major component libraries -if you report the bugs timely.
As to ajaxical stuff, JSF 2.0 indeed provides very little manual control over manually firing ajaxical requests and controlling the view tree in both server and client side. Simply because it's a component based MVC framework which keeps the tree state at the both sides. You've got to take the both sides into account when taking the ajaxical works in your own hands. If you really need more freedom in ajax/request based actions, then a component based MVC framework is simply the wrong choice. You should pick a request/action based MVC framework instead like Spring MVC, Struts or Stripes, along with a JS library like jQuery. You however have to write lot of HTML/CSS/JS boilerplate yourself instead.