|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 15
Messages: 15
Messages: 15
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Introduction to Spring Faces Part 1
As part of the recent final release of Spring Web Flow 2, along comes the official introduction of the Spring Faces module. This module builds on the foundation of Spring MVC and Spring Web Flow (SWF) to provide first-class integration support between JavaServer Faces (JSF) and Spring. Spring has long included basic JSF integration in its web module, which by itself provides the necessary glue between a typical JSF web layer and a Spring managed business layer. This integration is what we today refer to as the JSF-centric way of integrating the two technologies. Though many applications have been built successfully using this approach, we on the Spring Web team felt that there was still a disconnect between the two, with too many artifacts and too much conceptual overhead to manage easily.
Spring Faces turns the table and approaches the integration from a different angle, with the goal of bringing the strengths of JSF to a Spring-driven web environment. At the same time, it alleviates many of the common frustrations that come with developing a traditional pure JSF web application. Spring Faces pushes the Spring programming model further up the stack, and advocates more of a "turtles all the way down" approach to using JSF with Spring. This is what we refer to as the Spring-centric approach to developing web applications with the JSF UI component model. This article aims to demonstrate the benefits of this approach and why it should appeal to JSF and Spring developers.
JSF and Spring - The perfect combination?
JSF by itself offers great benefits when you are developing rich web applications, especially when they have complex user interactions that stand to benefit from a stateful programming model. Its UI component model is solid and powerful. When applied appropriately, it achieves well its goals of shielding you from the complexities involved in building rich UI controls in a web browser. The ability to declaratively build a rich user interface, combined with the flexible binding of the values of individual controls directly to your domain model through the Unified Expression Language (EL), enables you to quickly build complex web user interfaces without having to worry about the internal mechanics of the components. All of this is achieved with a simple POJO programming model.
Spring is a natural fit and the logical choice for the domain layer of a JSF-fronted application, as it enables a similar POJO programming model. By taking advantage of a few of JSF's many well-defined extension points, it's simple to plug a Spring-powered business layer into a JSF front-end.
JSF-centric integration via EL
In the JSF-centric approach to integration, the JSF controller model is driving the application and JSF managed beans delegate to Spring for business-layer concerns. Spring provides several integration classes that can be selected and used a la carte by configuring them in faces-config.xml. The most widely used of these classes is the DelegatingVariableResolver (and the JSF 1.2 equivalent SpringBeanFacesELResolver). This class effectively makes Spring beans resolvable via EL expressions. The typical usage pattern is to use EL to inject Spring beans into JSF managed beans. For example, if you have the following simple Spring bean defined in your WebApplicationContext:
<bean id="mySpringService" class="com.foo.MySpringServiceImpl">
You can then use EL to inject that service into a JSF managed bean by referencing it in the <managed-bean> definition in faces-config.xml. In the JSF-centric approach to integration, the JSF controller model is driving the application and JSF managed beans delegate to Spring for business-layer concerns. Spring provides several integration classes that can be selected and used a la carte by configuring them in faces-config.xml. The most widely used of these classes is the DelegatingVariableResolver (and the JSF 1.2 equivalent SpringBeanFacesELResolver). This class effectively makes Spring beans resolvable via EL expressions. The typical usage pattern is to use EL to inject Spring beans into JSF managed beans. For example, if you have the following simple Spring bean defined in your WebApplicationContext:
<managed-bean> <managed-bean-name>myJsfManagedBean</managed-bean-name> <managed-bean-class>com.foo.MyJsfManagedBean</managed-bean-class> <managed-bean-scope>request</managed-bean-scope> <managed-property> <property-name>mySpringService</property-name> <value>#{mySpringService}</value> </managed-property> </managed-bean>
This results in the Spring managed singleton service getting injected into the JSF managed bean every time an instance of the bean is created by JSF. As of Spring 2.0, where you have the ability to have request and session scoped Spring beans, you can even eliminate the JSF managed beans altogether, and simply rely on the Spring container to instantiate and manage the beans the first time they are referenced via an EL expression.
Does the JSF-centric approach go far enough?
With Spring's simple JSF integration classes, you can smoothly integrate Spring managed services into a JSF-driven front end. But does this go far enough? I would assert that it does not, and that this approach in fact leaves much to be desired. For one, it assumes that the traditional JSF controller model is adequate, when in practice it has proven to have several deficiencies:
* With it's pull-MVC approach, everything is driven by the rendering of the view, with no convenient points for initialization of the model prior to rendering.
* The cumbersome navigation model gives little or no feedback when you make a mistake (such as misspelling a navigation outcome) and requires an application restart anytime a rule is added or modified.
* The validation model doesn't go far enough, as it is focused mainly on individual field-level validation only on the server-side. A convenient way of being able to do client-side field validation and server-side model-level validation without having to navigate the component tree is sorely needed.
* URL mapping is rather inflexible and the URL is usually a step behind unless you perform a redirect. The redirect support is generally not sufficient, as certain things like FacesMessages do not get preserved across the redirect.
* Finer-grained scopes in between request and session scope are commonly needed, especially when working with Ajax-based views that fire multiple in-page events.
* Exception handling capabilities are quite limited, especially if they occur during view rendering (which can often be the case in using the pull-MVC approach).
* Control logic gets spread throughout JSF managed beans, which can be difficult to unit test and require an application restart anytime changes are made.
JSF's UI component model is solid; it allows rich behavior to be encapsulated and executed within the well-defined boundaries of the JSF component lifecycle. However its controller model is rather limited, especially to someone who is used to the power and flexibility of Spring, Spring MVC, and Spring Web Flow. The JSF-centric approach to integration introduces an extreme amount of conceptual overhead, since you have to continually manage many disparate artifacts, such as faces-config.xml, JSF managed beans, JSF view templates, and all of the components of your Spring-based business layer.
Initially, Spring Web Flow 1.x also attempted to integrate in a JSF-centric way, but this approach proved to have numerous limitations. It required yet more JSF artifacts to be chosen a la carte and manually added to the faces-config.xml in order to function properly, introducing further conceptual complexity. This approach was by no means agile.
We decided that what would be ideal was if the strengths of JSF's UI component model could be integrated into a Spring environment, while pushing the Spring programming model further up the stack for a more Spring-centric approach. If you could let Spring be in control of the entire request, you could have a consistent programming and configuration model throughout the entire application. You could also take full advantage of Spring MVC's flexible routing infrastructure and Spring Web Flow 2.x's agile stateful controller model, which is a natural fit with stateful JSF views. This is the motivation for the creation of Spring Faces and its addition to the Spring portfolio.
Spring-centric JSF with Spring Faces
Spring Faces takes a much more prescriptive approach to integration between JSF and Spring. A further strength of JSF is the many extension points it provides, and Spring Faces takes full advantage of this to fit JSF more naturally into a Spring world. It makes a number of assumptions about the environment it is running in, such as a Spring MVC DispatcherServlet being configured to handle request routing, and Spring Web Flow 2.x being available as the primary controller model. It also builds upon the new Spring JavaScript module to provide a number of lightweight JSF Ajax components that focus on web development best practices, such as progressive enhancement, graceful degradation, and accessibility. (Spring Faces is designed to work with any JSF component library, thus the use of these components is entirely optional.)
For the remainder of this article, I will be using pieces of the Spring Faces version of the Spring Travel sample application (included in the Spring Web Flow 2 distribution ) to illustrate the Spring Faces approach to building a JSF web application.
The full source for the Spring Faces sample can be found under /projects/spring-webflow-samples/booking-faces/ from the root of the distribution.
If you want to at least familiarize yourself with the functionality of the application, a running version of the sample is available here.
Structure of the Spring Faces sample
One of the first things worth noting about the sample is the content of /src/main/webapp/WEB-INF/faces-config.xml. The only piece of infrastructure configured there is the standard FaceletViewHandler. Since Spring Faces takes a more prescriptive approach, all of its JSF integration artifacts are configured automatically through inclusion of spring-faces.jar on the classpath.
You will also want to familiarize yourself with the basic setup for the routing infrastructure of the application by looking at:
* /src/main/webapp/WEB-INF/web.xml
* /src/main/webapp/WEB-INF/config/webmvc-config.xml
* /src/main/webapp/WEB-INF/config/webflow-config.xml
I won't explore the gory details of the configuration here, as that is well covered in the Spring Web Flow 2 Reference Guide, but I will briefly examine the result of this configuration.
All requests that have a /spring path get routed through the Spring DispatcherServlet. The DispatcherServlet then looks at the rest of the URL and selects either a stateless JSF view to render, or it hands control over to SWF for rendering of a stateful JSF view.
So for example:
/spring/intro -> renders the stateless Facelets template at /WEB-INF/intro.xhtml
/spring/main -> hands control over to the flow defined at /WEB-INF/flows/main/main.xml
/spring/booking?hotelId=5 -> hands control over to the flow defined at /WEB-INF/flows/booking/booking.xml, passing the hotelId parameter as input to the flow
As you can see by examining the contents of the /flows directory Spring Faces enables and encourages the organization of controller and view artifacts into logical re-usable modules.
Agile JSF controllers with Spring Web Flow
The core power of Spring Faces comes from its deep integration with Spring Web Flow, and the ability to use the high-level flow DSL that provides concise and elegant constructs for event handling, domain model orchestration, and view navigation. Flow definitions are dynamic and hot-refreshable without an application restart, as well as fully unit-testable standalone without having to be deployed to the web container. This gives you a much more agile JSF development process that can better keep pace with the flow of ideas. Its finer-grained scopes (flash, view, and flow scopes) allow you to work directly with your domain model across multiple requests, so you can focus more energy on adding value to your domain model and spend less time worrying about the infrastructural concerns of saving and restoring the model on every request. This stateful nature makes for an excellent pairing with rich JSF views, where the model needs to be frequently manipulated in response to multiple events.
With Spring Faces, the JSF postback lifecycle is executed under the control of SWF. As opposed to SWF 1.x's limited integration approach where the flow execution was wedged into the JSF lifecycle via a PhaseListener, the Spring Faces JSF extension points build directly on SWF constructs. This allows for several architectural advances that weren't previously possible such as:
* JSF views now work smoothly with SWF's automatic POST+Redirect+GET behavior, eliminating the step-behind-URL and browser refresh warning problems inherent in typical JSF applications.
* FacesMessages are adapted to and from Spring Binding's lower-level web-independent MessageContext, providing deep integration with Spring's strong i18n support. Messages are stored in flash scope so that they will be preserved across redirects.
* The component tree state is automatically synchronized with the flow execution state, with pluggable storage mechanisms to allow handling of various clustering scenarios
All of the integration classes use the standard JSF delegation approach, so for non-Spring requests, everything will pass through to the default implementation. This allows you to incrementally introduce Spring Faces into a traditional JSF application. In the next installment, I'll examine in detail some of the code from the sample application, to show how SWF addresses the aforementioned deficiencies of the traditional JSF controller model, and enables the "Spring all the way down" approach.
About the Author
Jeremy Grelle is a senior software engineer with SpringSource and the technical lead of the Spring Faces project, which provides first-class integration between Spring and Java Server Faces. He is a software artisan with extensive experience in combining server-side Java with the latest web browser technologies to deliver a rich and usable experience for the end user on the web. He has worked heavily with JSF since its initial release and is a member of the JSR-314 Expert Group for JSF 2.0.
http://www.jsfcentral.com/articles/intro_spring_faces_1.html
|
|
|
Message #272018
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Introduction to Spring Faces Part 1
For me, Hibernate + ZK + Spring is the best MVC design pattern.
|
|
|
Message #272052
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jump the shark
I think Spring Source have jumped the shark by going anywhere near JSF.
Webflow 1 rocked, in that it solved a huge number of problems that would otherwise require a roll-your-own solution, e.g. extra scopes (flash, conversation, flow), post-redirect-get support, the very notion of scripting flows together with multiple named in/out params between flows. Awesome stuff. Rich navigation out of the box.
On top of webflow, using Sitemesh + JSP .tag files + jQuery (or insert your favourite JS library here) pretty much provides everything I need in the UI layer.
No matter how hard I try, I still can't get my head around the concept of JSF being so server-side oriented.
I mean, I use Dreamweaver and the Adobe tools and still fail to see how JSF is ever going to look any good compared to the alternatives. My second pick would be Flex depending on the level of adventure that the customer has.
Not trying to flame anyone here, I just think "the emperor has no clothes", watch amusingly at all the JSF hype, and wonder when it will die a death like entity beans.
I also wonder if SpringSource did this so they could tick the "We're JSF compliant box" ??
|
|
|
Message #272053
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jump the shark
Greg
You don't need to use JSF with Spring Web Flow. The distribution contains both MVC and JSF-based samples.
One aim in SWF 2.0 was to ensure that people who want to use JSF can still benefit from SWF, and that SWF flows work with a wider choice of view technology. There are many other enhancements (such as simpler flow definitions and many new features) that benefit all SWF users, even if they are not interested in JSF.
Our view is that it's up to developers whether they want to use JSF, not up to us. Whatever their choice, we hope that SWF will provide them with significant value.
Rgds
Rod
|
|
|
Message #272054
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jump the shark
Hi Greg,
I think everyone can agree JSF, as a stateful UI component technology, is not appropriate for all projects. I do think JSF has its place, and at SpringSource we do have customer demand for first-class JSF support in Spring. So the goal of the Spring Faces project is to provide that first-class JSF support by integrating JSF with Spring Framework and Spring Web Flow. Basically, it lets JSF developers combine the strengths of JSF with the strengths of Spring, as Jeremy's article outlines.
It is important to understand Spring Faces is simply another tool in your toolbox. If JSF is not the best choice for your project, then don't use Spring Faces. Spring Framework, Spring Web Flow, Spring Security, Spring JavaScript, and all your other Spring projects work equally well with other view technologies, including the ones you mentioned.
We would never do something just to check some compliance box. There was a lot of careful thought put into how a UI component framework like JSF could be properly integrated into existing Spring technologies at an architectural level. The architectural fit was there, and this research also had the positive effect of enabling general improvements to the core of some of our runtimes, Web Flow 2 in particular.
Keith
SpringSource Principal and Co-Founder
Lead, Spring Web Flow
|
|
|
Message #272057
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jump the shark
Greg
You don't need to use JSF with Spring Web Flow.
Hi Rod,
I know it's optional. It still surprised me to see Spring support JSF given that you were the one who poked great big holes through J2EE way back in the Expert One-on-One book. JSF seems similar to J2EE in that regard, i.e. a lot of hoopla about nothing - compared to a Sitemesh, jQuery, .tag, Adobe approach.
It surprised me as much as if you had released a "Have fun with Entity Beans" book.
One comment on webflow 2 is that it would have been nice if it was backwards compatible with webflow 1 flow definitions. I need to take a closer look but I kind of like in webflow 1 having a *FormAction class which has a bunch of methods with the following signature
public Event doSomething(RequestContext context)
It lets me keep as much code as possible in Java and checkable by the compiler rather than having more mapping *variation* in webflow XML files. That is, it *seems* like programming in XML under webflow 2.
Unit testing of the flow under webflow 2 seems a whole lot more important due to that variation and increased complexity in XML mapping, but I need to take a closer look. I haven't really done anything with webflow 2 yet.
Regards,
|
|
|
Message #272076
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jump the shark
I know it's optional. It still surprised me to see Spring support JSF given that you were the one who poked great big holes through J2EE way back in the Expert One-on-One book. JSF seems similar to J2EE in that regard, i.e. a lot of hoopla about nothing - compared to a Sitemesh, jQuery, .tag, Adobe approach.
It surprised me as much as if you had released a "Have fun with Entity Beans" book. Well... IIRC, Rod never said "entity beans are always wrong." (Maybe I'm in error... my copies of Rod's books are about 200 miles away from me right now.)
EJB 2.x Entity beans are the right solution to... well... a very narrow set of problems that you're not likely to run into very often, as it turns out. If you have THAT PROBLEM, then maybe they're the right solution, and I'd be surprised if Rod didn't support them in that case.
JSF has its own use cases. It's not a bad technology; it's also not a perfect or omnipresent technology. Spring supporting JSF means good things for JSF and good things for Spring.
|
|
|
Message #272093
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Unfair criticism
I use Dreamweaver and the Adobe tools and still fail to see how JSF is ever going to look any good compared to the alternatives.
Hey Greg,
I also use the Adobe tools and my development team uses JSF extensively. Like you I am very impressed with the quality of Adobe's products, and their innovation with Flash, Flex and other technologies.
What I like about JSF is the clean MVC2 design, stable API, extensibility, large number of third-party UI component libraries, and more.
My company has tried to bring together the best of both worlds by allowing web designers to work on JSF applications with Adobe tools.
I was testing our JSF extensions in Adobe Dreamweaver CS4 recently and I was amazed; I have yet to see such a stunningly beautiful UI development environment.
Combined with the now hundreds of JSF UI components available, I think JSF and Dreamweaver are an excellent set of tools for Java web development.
JSF is not an alternative to Adobe tools; you can easily use Adobe tools for JSF development. Dreamweaver aside, you can also use FlexBuilder to create Flex widgets and then wrap them with Fiji tags or JSF Flex tags.
JSF is not perfect, but it's still evolving and the EG is responsive to features requests, bug reports, etc. I think the JSF community is healthy and many companies and individuals are getting involved in the JSF ecosystem on mailing lists, at conferences, Java users groups, etc.
Your analogy with entity beans is misplaced. I think a better analogy would be EJB 2.x and EJB3. JSF is evolving; just look at how Facelets is now standard in JSF 2.0 and how Ajax will be standardized. In time I think JSF will evolve just like EJB did.
I think some of the criticism JSF receives is targeted at plain JSF (that is, JSF without any third party add-ons such as Seam, Facelets, etc). I have to remind these critics that JSF was designed to be extended and this is not a flaw in the framework.
It's good to see the Spring Faces project brings more Spring integration into the JSF space.
Ian Hlavats
JSFToolbox - Design JSF pages in Dreamweaver
|
|
|
Message #272119
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Unfair criticism
Ian,
A bit off topic here...
Curious... What tools do you use with Dreamweaver for JSF development. I am also interested in the tools which work for both CS3 and CS4 releases of DW.
Thanks,
Yaakov.
|
|
|
Message #272120
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Unfair criticism
Ian,
A bit off topic here...
Curious... What tools do you use with Dreamweaver for JSF development. I am also interested in the tools which work for both CS3 and CS4 releases of DW.
Thanks,
Yaakov.
Hi Yaakov,
My company develops JSF extensions for Dreamweaver. Please see our website, http://www.jsftoolbox.com.
We have Dreamweaver extensions for JSF Core/HTML, Facelets, Seam, Apache Tomahawk/Trinidad, and ICEfaces components (over 300+ components), and we are planning on supporting even more JSF component suites in 2009.
Our extensions include a wide range of design-time support for JSF UI development in Dreamweaver.
I demoed some of these new features at JSFOne this past September.
You can also read about our tools on JSFCentral.com.
We have a major release coming up that will include support for DW CS3 and CS4 and more... stay tuned.
Thanks for your interest!
Ian
|
|
|
Message #272127
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Unfair criticism
What I like about JSF is the clean MVC2 design, stable API, extensibility, large number of third-party UI component libraries, and more.
For something that's been "evolving" now for, what?, 6-7+ years, it's still quite complicated, kludgy, and generally off the mark.
By 'off the mark', JSF doesn't really solve any problems that I need solved -- rich navigation, Post-Redirect-Get support, extra scopes (flow, conversation, flash). It takes SpringSource to bolt JSF + webflow together to make JSF usable (for some victims). It surprises me that supposed web toolkits still get released that don't support the above features.
Bunging some jQuery code into a JSP page, or a .tag that retrieves JSON data via AJAX is pretty damn easy, and avoids black box pain that JSF delivers.
On component libraries, I don't want a "large number of third-party UI component libraries". I tend to build public facing sites, and have found rich navigation + dumb pages (with touches of jQuery/JSON/AJAX) works fine.
I've also been fairly horrified at the volume of HTML that typically appears in JSF pages when you view source in the browser. I prefer to have complete control over that for performance reasons, and yes it does make a big difference esp. for a larger number of users.
|
|
|
Message #272131
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jump the shark
I know it's optional. It still surprised me to see Spring support JSF given that you were the one who poked great big holes through J2EE way back in the Expert One-on-One book. JSF seems similar to J2EE in that regard, i.e. a lot of hoopla about nothing - compared to a Sitemesh, jQuery, .tag, Adobe approach.
It surprised me as much as if you had released a "Have fun with Entity Beans" book.
Spring is no longer the leftist (or progressive, to be accurate) student it used to be. It is now a middle aged entrepreneur :-)
|
|
|
Message #272171
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Introduction to Spring Faces Part 1
Spring Faces is a very good initiative.
I agree JSF support was not good and it took years to get mature. But now we should focus on present and in present JSF 1.2.9 + Facelets 1.14 + Seam 2.x + Rich Faces 3.2.x OR IceFaces OR WoodStock 4.3 + Ajax4JSF together with Spring makes a very strong and professional web framework stack.
We are just finished with a very large project in BI SOA domain using JSF(many CRUDS and some Dashboards) + Facelets + Seam + AJAX and RichFaces and we are v happy with overall productivity and good looking GUIs.
With JSF 2.0 is just a month away and many things are getting fixed Get + EzComp + Ajax + PDL + Skinning + Facelets etc. My experience is JSF is getting good day by day. Companies like JBoss,IBM , Oracle, BEA etc are supporting it.
Netbeans 6.5 has good JSF CRUD generator, means challenging Rails productivity and getting your web apps up quickly.
Nothing is perfect and we can always learn and improve.
Spring and SEAM supports conversational scopes, Rest, Bean Outjection this all is really very promising.
We should now start talking about how to make it more next generation( integrating with something like JavaFX etc, more client side).
|
|
|
Message #272195
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why not just use Seam pageflow
Why not just use Seam pageflow instead? It's much more natural to JSF. *sigh* Spring doesn't provide overall solution to JSF unlike Seam.
|
|
|
Message #272469
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ZK and Spring Web Flow Integration
Hi Keith,
This is Henri Chen from ZK project(open source Java Ajax Framework, http://www.zkoss.org). We are doing ZK and Spring Web Flow integration. I wonder if we can have some discussion on what is the best way to do such integration.
I have had some progress but do need some suggestions from the original author of the Spring Web Flow.
Thanks in advance. My email is henrichen AT zkoss DOT org.
Best regards,
Henri Chen
The ZK Team
http://www.zkoss.org
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
