Just finished the first day at JBoss World 2008. There is no center theme, but there is certain buzz about the JBoss Developer Studio. The Studio features a great set of tools to get started with Seam Development. The demos are certainly outstanding and has made developers eager to try it out. As far as I gathered it is Eclipse based, but plugins for IDEs will be forthcoming.
The Keynote gave clarity to how jboss.org is set up for open-source development and community, and jboss.com is the production and support based website that will be their money maker.
The Introduction To Seam presentation got a lot of fanfare, so much so, that I wasn't able to get in on it. That's OK since I know Seam anyway. The BOF by far was the best part and perhaps the 2nd best reason for coming (the 1st being that I will be presenting Agile Development using JBoss Seam on Friday). I got a few of my questions out of the way.
My first question, was how to get rid of more of LIES (LazyInitializationExceptions) other than just use the SMPC. Pete Muir and Gavin King helped to explain that if I have a session scoped entity bean for example and have a conversation based session bean that has reference on the entity bean, then that session will naturally have issues with transaction locking and produce the LazyInitializationException. The overall answer was that LIES should never happen in JBoss Seam, and if you get the error message in anyway then you are obviously doing something wrong. I am going to have to research more about the scoping and workarounds and I will have an article posted either here on my blog, or in the seamframework.org website.
That brings me a to a great segue, the Seam Framework website is up and running out of alpha, and I got to say, that is absolutely impressive. If you need to see a complete implementation of jboss seam in a production environment sign up and try it.
The other question I asked is how I can inject components into my validators and converters in JSF without using Component.getInstance("<<component name>>"). Using the getInstance method of course makes testing very difficult. Pete Muir explained that their hands were tied. The reason for @BypassInterceptors and the use Component.getInstance("<<component name>>") is because jsf reserializes the validator or converter object, and in the JSF domain it cannot recognize the @In annotation and provide the correct injection.
That's it for now....currently I am attending the 2nd keynote with a complete "business value, paradigm shift, SOA, value added, ROI, service mix" happy business feel good discussion.
The Keynote gave clarity to how jboss.org is set up for open-source development and community, and jboss.com is the production and support based website that will be their money maker.
The Introduction To Seam presentation got a lot of fanfare, so much so, that I wasn't able to get in on it. That's OK since I know Seam anyway. The BOF by far was the best part and perhaps the 2nd best reason for coming (the 1st being that I will be presenting Agile Development using JBoss Seam on Friday). I got a few of my questions out of the way.
My first question, was how to get rid of more of LIES (LazyInitializationExceptions) other than just use the SMPC. Pete Muir and Gavin King helped to explain that if I have a session scoped entity bean for example and have a conversation based session bean that has reference on the entity bean, then that session will naturally have issues with transaction locking and produce the LazyInitializationException. The overall answer was that LIES should never happen in JBoss Seam, and if you get the error message in anyway then you are obviously doing something wrong. I am going to have to research more about the scoping and workarounds and I will have an article posted either here on my blog, or in the seamframework.org website.
That brings me a to a great segue, the Seam Framework website is up and running out of alpha, and I got to say, that is absolutely impressive. If you need to see a complete implementation of jboss seam in a production environment sign up and try it.
The other question I asked is how I can inject components into my validators and converters in JSF without using Component.getInstance("<<component name>>"). Using the getInstance method of course makes testing very difficult. Pete Muir explained that their hands were tied. The reason for @BypassInterceptors and the use Component.getInstance("<<component name>>") is because jsf reserializes the validator or converter object, and in the JSF domain it cannot recognize the @In annotation and provide the correct injection.
That's it for now....currently I am attending the 2nd keynote with a complete "business value, paradigm shift, SOA, value added, ROI, service mix" happy business feel good discussion.