JSF Central - JSFCentral Podcast #24: Juergen Hoeller on Spring 3.1, JSF, and more
JSF Central

 Articles & Books 
Community Chat
JSFCentral Podcast #24: Juergen Hoeller on Spring 3.1, JSF, and more
by Kito Mann
20 Jan 2012 03:00 EST

In this podcast, JSFCentral editor-in-chief Kito D. Mann discusses Spring Framework 3.0 and Spring's support for JSF with Juergen Hoeller.

Podcast (MP3)
Welcome to the JSFCentral podcast #24 for the week of December 12, 2011. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology. This interview was recorded in April of 2011.
Kito Hello. My name is Kito Mann, and I'm here at CONFESS 2011 in Vienna, Austria. CONFESS is the new name for the JSFDays conference run by the Irian folks here who do a lot of the MyFaces development and support. I'm here today with Juergen Hoeller, and he is -- actually, what is your technical title? I know you're one of the cofounders of SpringSource, but what do they call you on a daily basis?
Juergen I'm the principal engineer at VMware now.
Kito Ah. Okay.
Juergen So, my official role is principal engineer, but I actually prefer calling myself the Spring Framework project lead because that's very much the role that I actually have. I've been doing this for about eight years now -- leading the Spring Framework project from one generation to the next. And this is very much still what I'm doing today: taking Spring Framework through development at this point, and taking it to the next level: Spring 3.1, Spring 3.2 that would be at this point. And so, my job responsibilities, actually, are a very stable arrangement. In this industry, eight years is a long time.
KitoThat’s true.
JuergenBut it keeps being a very interesting challenge because Spring has quite some history, and at the same time, it has a track record of embracing new trends and embracing new API generation. So we have a history in terms of backwards compatibility, and at the same time, we are often ahead of the curve; ahead of the time in adopting new standards, new trends, new specifications, new JDK generations. That keeps being very interesting because now in 2011, actually, things are becoming more diverse. There is so much happening.

And with the Spring Framework, we are really at the center of…where many things that are happening at the moment have an impact on what we are doing. And I find it very interesting, a very positive challenge, personally, because I keep being involved in so many interesting ongoing things, and I keep watching interesting industry trends that just have so much impact on the way that we are developing applications today, on the way forward, and also in terms of system architectures. So, many of those things really have a fundamental impact on the system architectures that we will be planning, will be constructing on the way forward, and I like that.

KitoI think also what's cool about your job is that you're focusing on Spring Framework, which out of all the Spring products, is…the portfolio is getting larger and larger as time goes on. But it's still the most widely used of them all, and the foundation for everything, which is kind of a nice area to work in because you also need to think about not only what developers want, but what the rest of SpringSource wants in terms of the other products.
Juergen That's very true, actually. I'm basically listening to everybody's requirements from all sides. And there are many sides, ranging from web flow and whole web based stack, but also now Roo, Grails, and Spring integration, like messaging oriented, event-driven architectures. All of those ongoing efforts, all of what they're doing has an impact -- some sort of impact -- on Spring Framework, of course. Some are requirements sent our way, or just something to consider, basically, on the way forward where new features, new modules that we are designing are just designed for use in so many different kinds of scenarios. And it's very much worth considering upfront, so I also tend to be very proactive about finding out where things are going in other Spring portfolio projects. Spring Framework may be the center of so many things, but it is driven and influenced by everything that goes on around it, within SpringSource and outside of SpringSource. But yet, even within SpringSource, there's already plenty to cover.
KitoYeah. And there's one other question I was wondering. I did a presentation yesterday about polyglot JSF, you know, different programming languages. I went through a very brief explanation of the scripting integration with Spring, and I was thinking, I didn't know if it had really changed much since 2.0, 2.5 in terms of what the features were because back then, there was support for Groovy, and Ruby, and BeanShell, usually with an interface in front. And I was just wondering -- has that changed in 3.0 or are there plans to change that?
Juergen Not at this point. Not specifically for the lang namespace and the ScriptFactory. Because that was kind of designed for a specific purpose, to add some dynamic elements to the actual production runtime. So you would define an interface that the rest of your application uses to interact with a more dynamic part, and that intentionally is living in a file that is being monitored. So some business rules -- for example, some delegation rules that may change, and you wouldn't want to restart your application -- you're putting them deliberately into a file that is hot-reloadable at production runtime. So that shows…I guess because for that kind of arrangement, you really need this strong interface based contract.

The whole mechanism hasn't really been designed for a broader use of either of those scripting languages in…like we're implementing all sorts of components. You would do that in other ways. So that's something to be kept in mind. But we're certainly seeing that. I mean, people are at least using Groovy. Actually that's quite mainstream, but then just using the Groovy compiler, basically, just compiling into class files and not actually relying on any dedicated framework or hot update supporter. Because you wouldn't want to do that for those kinds of components, only for selected ones. And at development time, I guess there would be a potential to provide a bit more explicit support for…like using Groovy to implement Spring based components, but it seems to be a pretty straightforward story even at this point.

It's primarily Groovy. I'm not really seeing that for JRuby, so that's a bit more esoteric, I guess, in terms of being used in a broader, wider context here, with Spring Framework component model in particular. And then also Scala, of course, would be a candidate as well these days, where people start experimenting with the combination of Scala and Spring. Kind of finding out what kind of roles Spring -- Spring itself as a framework, but also Spring's patterns, and Spring's kind of conventions -- really have in a Scala world.

It's not actually a trivial question. Scala has its own ways of doing things in quite a few respects. And we’re also actively investing into that kind of space, where we're just trying to find out for ourselves where things really fit together, and what we could do about making things smoother in combination. And Scala certainly is one of the more interesting candidates in this space, at the moment. With Groovy, it's actually quite straightforward, because Groovy has such a strong Java orientation anyway. So, in that sense, it's quite natural without doing much about it, really.

KitoYeah. It's interesting because since Scala does compile to classes, on the surface -- at least from that perspective -- it seems to fit better. But in terms of where you can go with the language, it could be completely different.
Juergen And where there would be just some breakage in style, in API style, and also in the component model. With Spring in particular, it's basically a component model and the configuration model, and both of them in combination need to make some sense with the language that you're using. With Java and Groovy, that's somewhat straightforward. With Scala, we have to find out where the ideal kind of combination is. So, we'll see. It could easily be that we will come up with some blueprints in that space. Maybe a sample application, we'll see, right?
KitoThat'd be nice.
JuergenIf there is demand for it, and maybe some people contributing, I could easily imagine that to come up actually quite soon.
Kito Do you find that most of your customers are still mostly Java? Or maybe 80 percent Java, 20 percent Groovy? What sort of languages are you seeing out there?
JuergenWell, I'm afraid I have no real statistically significant numbers in this respect, but it's certainly strongly Java based. And particularly, if you're saying customers -- as opposed to Open Source users -- it's definitely way above 90 percent that are basically using the Java language, at least for most of their systems. They may use Groovy for specific parts. They may use a bit of scripting or integration with other dynamic, with the sales and support, so some dynamic elements. But generally, they are usually Java shops -- pretty traditional in that sense.

And we find out again and again that basically upgrading their mental way of dealing with Java to a Java 5.0, Java 6.0 level -- it's not happening automatically in all of those places, right? I mean, many of them have actual code bases started back in the Java 1.03, 1.04 days, and they kind of only slowly get there. So embracing annotations, and embracing generics is something… Like, really embracing it in their own types, in their own APIs, and going beyond the obvious, going beyond the pieces that they get out of the box -- that's not really happening very often.

And we also find it to be the case with Spring Framework's facilities in this space, where the richness and just the power behind the Spring annotation base component model -- they only really start touching that power, right? They don't dive very deep; it's not a deep dive at this point. Again, with the Spring's annotation based support, they may use annotation based dependency injection, for example. They may use a post-constructed pre-destroy, but they're not really using the stereotype model, which is actually quite powerful. They may use a transactional, but it's more the basic, the obvious stuff, right? But then, Spring has so much more: composable stereotype model, configuration classes, the power of annotated factory methods. And they're only really starting to explore that. Even at this point, they're only really starting to explore that.

And well, that's not a bad thing, I mean, we don't mind. But it just shows that even in the standard Java language world, basically, the world is only really about to catch up with everything that you can do in that space. So I guess that also explains why there's Java shops, basically. They're not even exploring those facilities fully if they went to Groovy -- there was so much more to explore, and maybe that would be too much to explore for them. They prefer a kind of simpler set of language fundamentals to deal with.

And yeah, implementing their own annotations, for example. Like writing their own annotations, like for meta annotation composition, even that kind of feels strange to them, if you explain to them that it's completely trivial. “Just write this public @Interface, and meta annotate with what you'd like to combine, and Spring will auto-detect it.” And they’re sort of like: “Should I really do that? My own annotation types?” And well, we're kind of trying to show them that this is actually a very natural thing to do; that the annotations are a natural part of the Java language, and just types like any other type, really, and can be used in a very custom fashion, if you choose to do so.

Kito So, you're talking about how a lot of the new features in Spring, specifically more 3.0 sort of features are still being slowly adopted. But you're looking to bring 3.1 now, so, tell us sort of in broad strokes what you're seeing for 3.1, and what the possible timeline might be.
Juergen Spring 3.1 is designed really as a quite natural next step after 3.0. So in 3.0 we made some leaps in Java 5+ upgrade through the entire Framework and so forth, and a lot of programming model features that really added to the comprehensiveness of the core programming model, core component model in Spring.

In 3.1, it's a bit different in terms of focus because we have more selective enhancements to specific areas…more than actually touching the core component model. So, there are a couple of things, like in the BeanDefinition world we do what we call environment profiles. So, they're kind of -- it's more of a high level addition, really, for just expressing conditions where BeanDefinitions would only be actually active if certain environment profiles are active. So, it basically allows for composing configuration, typically XMLBean configuration, in a way where the configuration kind of reacts to active profiles at runtime. The very same deployment unit, the very same configuration file without modification could, therefore, just expose different adapter types, different integration lookups based on whether it is in production or in testing…or maybe based on whether it deploys to WebSphere, or whether it's being deployed to a more Tomcat-oriented oriented stack. So it's really a very minimal edition. It's technically not very complex, not in implementation, and not in usage. But it allows for just so many different ways of using it, and so many things to express based on the profile mechanism. It really is a nice addition to the BeanDefinition world.

We also have an ongoing focus on Java based application configuration, which is kind of @Configuration++. So, Spring 3.0 saw the introduction of the configuration class, the former Spring/Java config project. Basically the ideas got rolled into the core component model in Spring Framework. And we had @Configuration classes with addBean factory[methods, a quite powerful mechanism in its own right. In Spring 3.1, we are trying to go just a little step further in allowing for application configuration, more higher level container configuration to be expressed in that style as well. Things like , or -- what you would typically use XML namespaces for. Those kinds of slightly higher level conveniences where it's not a single bean that you're configuring, it's more of like a bunch of related infrastructural concerns that you're expressing, and some BeanDefinitions coming out of that underneath the covers. That's really what we're doing; we're trying to come up with a nice, straightforward mechanism where within the @Configuration class model, you could also express a , instruction, and those sorts of things, in interaction with the standard configuration model. So, that's also in -- and there's already a cut of that in 3.1.0 just like for environment profiles.

And then, there's the cache abstraction, which is kind of quite separate, I think. But it actually is something we meant to do for such a long time. We had liked the idea of doing a cache abstraction probably back in 2004. But we also had a cache package, an org.springframework.cache package for such a long time, but it was basically always empty, except for two factory beans in the ehcache sub-package. So, we're now filling the package with a proper cache abstraction. Probably the most interesting part actually is the declarative caching facility where we have a set of caching annotations that allow for expressing typical cache interaction patterns through the use of an @Cacheable annotation and an @CacheEvict annotation. That turns out to be quite nice, quite elegant, instead of doing the usual [cache gets, if not found, then cache puts] interaction pattern in programmatic form. We basically wrap the target component with an interceptor that just does that kind of check for you, computes the cache key from the method signature, takes the return value as the actual cache value. That works very nicely and it's built on top of the cache abstraction, so it requires some sort of cache abstraction underneath. But it probably is the nicest entry point into the caching subsystem.

So, that's also Spring 3.1. And then, there are a couple of minor things. But nevertheless, really, nice things like the c-namespace for constructor argument shortcuts where we're basically providing a way to have inline constructor argument definitions in a bean -- XMLBean element. We had it for properties, in the form of the “p” namespace, and now we're doing it for constructor arguments in the form of the “c” namespace. And using named constructors you know, so it's like … so it's really… It's a concise, readable style with a little twist, because it requires access to constructor argument names. Of course, in Java there are no constructor argument names formally at runtime, so we're doing some tricks there with relying on the debug symbols, and reading them through ASM. We had that facility in Spring 3.0 for other purposes, like AspectJ integration, and we're basically using the same fundamental facility now for the c-namespace, for constructor arguments, access by name.

So, with just a little trick, basically, it's really convenient, a nice arrangement falling from it, because that turns out to be a common kind of scenario: people really wanting to use constructor arguments, and kind of trading it off with bean properties for readability because bean properties are named. But actually, they meant to use constructor arguments because it is immutable state, they would like to store it in final variables. And so, we're kind of trying to make this as convenient as possible, just as convenient as properties are. So, we're also enhancing things in that space, in multi-concise, XML configuration side of the world. Not just in the annotation space, we're investing in both first-class BeanDefinition models that we have in here.

That's pretty much what we actually shipped in Spring 3.1.0. And there are a couple of further things still on the roadmap. Spring 3.1 is basically -- it's quite complete in its planning, so there's just a second milestone, no more than that. And the second milestone has a bit of a web focus. So, it focuses on Spring MVC enhancements, and a bit of an opening up for customization purposes.

And then also, it goes into the conversation management space where we have a couple of related ideas, and related contributions. Not just for actual conversation management, but also for this idea of a window session, a window scope where basically, people… All that people want in that space is kind of an HTTP session for variance that happens to provide some window isolation, instead of being shared across browser windows and browser tabs. This is like this notion of window isolation, and the window session scope is something we have a great solution for.

And then very related to that, conversation management is about an abstraction, basically: a couple of API types that application components typically interact with when talking to conversation scoped components, or when wanting access to conversation attributes when instructing a conversation manager. It's really just very basic interaction patterns, but at the moment, there is no common ground in this space. There are so many conversation space solutions, conversation oriented solutions, conversation scopes of some form, but they have their own ways of doing things, their own semantics, their own API types.

That even applies to CDI, which actually has a conversation abstraction. But at the same time, you have My Face's CODI kind of bypassing the standard CDI conversations…being a CDI extension, but bypassing CDI conversations and introducing its own conversation model, with its own APIs and its own semantics. For a good reason in that case, but nevertheless, there is not much common ground at this point. My Face's Orchestra, again, has its own ways, and Web Flow -- Spring Web Flow has its own ways. And we're really trying to just provide the most basic API type here in Spring Framework, that hopefully all the Spring-related conversation solutions could agree on integrating with, so that they would expose or satisfy those API requirements in some form.

The most important part there is access to a current conversation. So, if you're within a specific call stack, basically there would be a kind of a thread bound current conversation that you could have uniform access to, down there somewhere in the surface layer, somewhere in the processing layer, where you wouldn't actually care where exactly the conversation came from. Whether it's web initiated conversation, or a messaging initiated conversation. It's kind of not that important; at that point, you just want access to this notion of a current conversation. So we're exploring some very basic arrangements in that space. That's really what the conversation management in Spring 3.1 will be about.

And last, but not least, we are exploring some Servlet 3.0. So, Servlet 3.0 has a revised configuration model, configuration approach, where there is this notion of a servlet container initializer, kind of a callback hook where you would programmatically register servlets and filters, and everything that you typically do in Web XML. But as an alternative to Web XML, you would express this in the form of a servlet container initializer. And that's a great fit with Spring's own Java based configuration model, annotation configure application context, and everything that follows from there. So, we are trying to provide some form of base classes, or common delegates for setting up a typical Spring based web application in the form of a servlet container initializer, avoiding Web XML…if you are on Servlet 3.0. And that actually should be quite nice, again, a readable and elegant affair. So, it would not just be an alternative way of doing the same, it might be a better way, more customizable, but all the more readable. A more extensible, reusable way of composing a servlet deployment unit, basically. So that's also something that really fits very well with the themes that we have already.

So that's pretty much what Spring 3.1 will be about. Not all of this is really related, but we're always trying to select a number of themes that kind of fit together very nicely, that go together nicely, and I would hope that shows in the Spring 3.1 plan.

KitoOkay, cool. Let's talk a little bit more about the conversation stuff because that's pretty relevant to JSF developers.

You are pretty much defining some core concepts of a conversation, and the window scope, and exposing those in the framework layer. How does that relate to the web layer? If I take a Spring MVC app today, or a JSF app today, do they automatically -- can I just automatically inject a conversation scope thing and it'll work? Or how does that actually play out?

JuergenIt is actually quite independent, technically. There is no close coupling to either Spring MVC or JSF, or any other web framework, really. But we'll certainly go the extra mile, in terms of making sure that there is actually some smooth integration with MVC and JSF, in particular.

With Spring MVC, I would expect the window isolation part to be the most popular. And very likely, basically a flag in where you switch your session attribute store -- that's what we're calling it -- onto the window based variant from the standard variant. So that would probably be very easy to consume, where regular @Controller session attributes would then just be stored in the windows session instead of the standard session. But for more flexible interaction, I would…in an MVC world, I could imagine that programmatic interaction with the current conversation would actually be quite a good way of going about it.

Whereas in the JSF world, the scoping model, the bean scopes -- like a conversation scope, a window session scope -- those would certainly be good entry points as well because it's just more common to create managed scoped beans for interaction in JSF than it is in MVC. In MVC, actually, the use of scoped beans is kind of…not that common. You would do it for a more specific purpose, like having session scoped components of some sort. But the actual interaction, like full interaction and so forth, is not expressed using scoped beans. Whereas in JSF, it typically is.

So, the access patterns may be a bit different in terms of the entry points into the conversation management part. But the infrastructure underneath should be the very same, so even if within the same application you've got some MVC and some JSF – that might easily be the case, actually, it's not uncommon -- then they should have some common ground in the form of the fundamental conversation management concepts, and also, conversation management APIs. That's really the plan.

All the existing solutions, we have yet to find out how they fit with this. I mean, they could certainly just be compliant, basically, with the core concepts that Spring 3.1 introduces. But at the same time, there is…even from a JSF perspective, as long as there is a scope called conversation here, you can actually have a pretty nice abstraction, even on that basis. So there might not be that much need for actual API interaction. There certainly is some need for API interaction in the messaging space, in the non-web space where just the creation of conversations and the termination of conversations tends to be a programmatic step. And even access to the current conversation could quite often be programmatic instead of using scoped beans or the like.

So, that's really the way it's designed, at least. We'll see how it works out. Depending on what the demand is, we certainly…we'll be exploring a higher level integration as well, if there is more specific integration, if we can. But the initial plan is to provide some immediate support for it in Spring MVC, and to provide good exposure to JSF based applications, and for it to make some sense in the messaging world. It's really the three cornerstones, for a start.

KitoSo, for developers who are working with Spring and JSF, there's a few different options, right? They can either use the default or the basic SpringFacesELResolver, I think that's the current one, right? I know there was another one before.
Kito And even on that level, they can either have some stuff as JSF managed beans, and some stuff as Spring Beans, or they can make everything Spring Beans. Or you can take a more Spring-centric approach, and use Spring Web Flow as the primary controller with JSF views. Tell us a little bit about like…which people or groups seem to be more interested in which approach, and kind of the pros and cons of the approaches.
Juergen For quite a while, basically we invested into both approaches, where Spring Faces is actually a kind of subcomponent of the Spring Web Flow project, so it's only been exposed through Web Flow. I would argue that the mainstream option certainly is the more traditional JSF-centric integration through an EL resolver where you basically replace the managed bean facility, or link the managed bean facility to Spring.

There is certainly…for any kind of stronger Spring integration, stronger use of Spring, chances are that you're probably defining all your managed beans in Spring, so that you're quite literally replacing the standard managed bean facility with Spring, and we're really trying to make it a smooth ride. Spring actually has some automated detection of JSF, of an active JSF Faces context in its web runtime. So for example, if you're using Scope Beans and so forth, and you're using expressions on any of those Beans, then we have implicit access to the same implicit variables that you would have in a Faces EL expression, which is primarily meant to be used for reuse of an existing manage BeanDefinition at the Faces layer. Just moving it to a Spring BeanDefinition and it just keeps working, including its expressions.

So, we're actually going quite a bit into the JSF specific space here, and just making sure that this is a smooth ride, that there is no artificial breakage between the JSF managed bean layer, and Spring as a managed bean layer. But then, this is all pretty much the standard, the more traditional, more mainstream arrangement. And lately, we tend to see this becoming kind of the prevalent model, the model on the way forward.

Now, with JSF 2.0 and JSF 2.1, and JSF 2.2, there is quite a bit happening in the actual JSF specification, in the actual JSF runtime. And this way of integrating JSF and Spring makes sure that there are no issues with upgrading JSF, any version of JSF basically can be combined with Spring that way, and it'll just work, even with existing Spring versions. So Spring doesn't have to have a new release just in order to work with JSF 2.1 or JSF 2.2. So there's a bit of decoupling, basically between the JSF version and the Spring version that you are using, and that's a good thing in this respect. Whereas with Spring Faces, the Web Flow driven initiative that we had there, the picture is very different.

Spring Faces is basically a Spring DispatcherServlet infrastructure that kind of drives the JSF request lifecycle. So, this is strongly coupled to a specific JSF version that it actually provides because it provides Faces context adapters, and so forth. And it's more of an experimental approach. At least that's what it originally was and in retrospect, that's what it still is to some degree. And it made quite a bit of sense in several scenarios, but from a modern JSF 2.x perspective, I'm not sure we would even advocate that approach over the more traditional integration. So we'll have to revisit this in the Web Flow 3 timeline. But I could easily imagine that not being part of Web Flow 3 anymore, where Web Flow itself centers on the more traditional JSF-centric Spring integration.

But that's part of our ongoing JSF investment. We also explore nontraditional ways of integrating with JSF. As it always is, not all of them are there for a lifetime…beyond a couple of years. I mean, it's also hard to just foresee where the world is going, where the world is turning, and the way that JSF specifications themselves are going. So, we're kind of trying to make some sense of it all, trying to provide an arrangement that keeps making sense, even with ongoing JSF specification enhancements. And JSF 2.1 and 2.2 are actually good examples of that, where we keep being involved in the expert group, and we are just trying to make sure that there is input from our side, and into the JSF specification. And well, there is at least the intention to do everything that we need to do, that we can do to make sure that Spring remains kind of a natural part of the JSF picture, the JSF-centric picture, even with JSF 2.1 and JSF 2.2 in the driver's seat.

In many ways, we are waiting for community feedback to find out where maybe the gaps are, or where we just can go the extra mile, and maybe don't do it at this point. We're certainly willing to listen. Because fundamentally, we have an open web strategy and JSF is a very important cornerstone in that. MVC, of course, is an area of investment on our side as well, but it's for quite a different kind of application. And then, we have other web frameworks, of course, as well, but in comparison to MVC and JSF, kind of all the others are kind of niches…sideshows. It's just the way it is if you look at the statistics. So Spring MVC, of course, remains very popular, in particular now, with the more restful server endpoint model where rich clients basically talk to a rather stateless servers, server endpoints. And it's a great fit for that. It kind of reinvented itself to be a great fit for that kind of world.

And JSF is like a quite different arrangement: different tradeoffs, more state-centric on the server in many ways, and a stronger focus on using the view state in particular. And those things really go together very nicely. They kind of operate to support at the same time. And it also helps in trying to come up with good general solutions -- like in the conversation management space -- if you're being driven by quite different architectures, quite different web architectures. So I really appreciate that. And in that sense, our strategy is really MVC and JSF-centric, to some degree. And then, there's a bit of JAX-RS here in the mix, maybe Wicket and Tapestry in the mix…

Kito And a little bit of Grails in there, too.
JuergenYeah. Of course, I'm talking about the Spring Framework strategy, specifically.
Kito Right. Right.
JuergenYou are very right. Of course, with Grails, we have then yet another quite distinct approach. But that's a bit of a different show, basically, because Grails is more than just a web framework, with GORM and all. It really is like a complete development experience of its own -- on an MVC basis, of course, underneath the covers, but people don't necessarily realize that. So Grails is quite special in that way. And even Roo, as a more traditional MVC based development experience, that is a bit special in its own way. It is more traditionally MVC based, so with Spring Roo, you're actually seeing Spring MVC quite natively, and it's quite of a best practice for, like, restful users of Spring MVC.
KitoI did though see that there's a JSF plugin for Roo, at least on the issue tracker under development or something. So maybe we'll see more along those lines.
Juergen Yeah. I haven't actually heard of any concrete steps in that space. But yeah, it would be interesting to find out what it would look like. Because JSF, of course, strongly also has its own tooling and its own using of its component libraries and so forth. So, it's very much already has a rich ecosystem where…yeah, it's not entirely obvious what Roo would be able to do…what role Roo could be playing here.

But certainly some of the strengths in the JSF space are the recent component libraries. So, something that we're also paying attention to are developments like PrimeFaces and more of the JSF 2.x oriented component libraries, it’s actually quite interesting to follow lately.

So, JSF 2.0 as a foundation kind of really managed to create a bit of an ecosystem of its own in the meantime: the JSF 2.0, 2.x ecosystem. That's a good thing. It's certainly something that we're really actively following, and just trying to also come up with some recommendations if like somebody approaches us and says “I'd like to do a JSF 2.0 Spring based application. What would you recommend?” We get those kinds of questions, right? So, we're also trying to form an opinion in that space, for that reason, basically. And the PrimeFaces would be like a part of that recommendation at that point, I guess.

KitoOkay. Alright. Well, I guess the main thing to take away here is that there's a really good integration here between Spring and JSF, as usual. Great stuff in Spring 3.1 coming along. And, of course, if you have any feedback on Spring 3.1 or JSF integration with Spring or if you guys are interested…
Juergen Let us know. Also with respect to JSF 2.1 and 2.2, and what we could do about that…already looking forward to planning ahead, being ahead of the time there. We'd certainly love to know about that.
KitoOkay. Alright. Well, I certainly appreciate you taking the time to chat.
Juergen It was my pleasure.
KitoAnd I'm sure I will see you around, and enjoy the rest of the conference. You're leaving tonight, right?
JuergenYeah. I am.
Kito Okay. Well, enjoy the rest of the day at the conference then. Thank you very much Juergen.
Juergen Thanks Kito
AnnouncerThat’s it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann. Thank you for listening…

RSS feed(all feeds)

The Editor's Desk
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.