The Source for Java Technology Collaboration
User: Password:
Register | Login help    

Search

Online Books:
java.net on MarkMail:


Ed Burns

Ed Burns is a senior staff engineer at Sun Microsystems. Ed has worked on a wide variety of client and server side web technologies since 1994, including NCSA Mosaic, Mozilla, the Sun Java Plugin, Jakarta Tomcat and, most recently JavaServer Faces. Ed is currently the co-spec lead for JavaServer Faces.

 

Ed Burns's blog

Project Idea: memcached JSF Component

Posted by edburns on November 23, 2009 at 12:14 PM PST

While speaking at the Globalcode Developer's conference in Rio de Janeiro, I met a dynamic and intelligent student by the name of Thiago Diogo. Thiaogo presented his group's work on student project to provide a real, mission critical distributed application for his university, Universidade Federal Fulminense. They chose JSF 1.2 and Seam as a part of their stack.

One idea Thiaogo shared with me was a memcached JSF component. We kicked the idea around and I mentioned it would be pretty easy to invent a JSF component that acted like a <span> tag that simply meant, “the rendered output of any JSF components inside of me should come from memcached, if possible”. I don't have time to start on this idea right now, so I thought I'd share it out here in my blog in case anyone else wanted to pick it up, or if anyone else has already done this! When I get time, I'll try adding it to the Mojarra sandbox components, but in the meantime, anyone can have at it!

Technorati Tags:

Related Topics >> Databases      Java Enterprise      Performance      Web Applications      
Comments
Comments are listed in date ascending order (oldest first)

Thanks to remember!

Hi Ed, thanks for the mention in your blog about the idea. My team want to help you with the development of this component. Here in our project we've created a @CacheResult annotation to be placed at the service's methods (we use the App Service pattern) to store in one memcached instance the return of that method for next calls. We can think in something like this to the creation of our component.
How can I and my team get involved with this component development?
Again, thanks for remember the idea. And we're waiting you here in Olympic Games 2016!
See you.

Use a neutral API

Ed, one of the components we have always had in Seam was the tag, which rendered any nested tags using cached output (we never ventured into allowing input components inside these regions, not sure if that is something you are envisaging?). Anyway, a mistake we made early on was to essentially tie the component to the JBoss Cache API (which we later retrofitted to a generic API). As a result I would recommend not tying yourself to any particular API, but instead use a neutral one. In general, Map is a great fit for a cache access (and maybe ConcurrentMap for adding stuff to the cache), so I would suggest using that. You could then provide a default implementation based on memcached (which is definitely a pseudo-standard API :-)
Syndicate content