1 2 3 Previous Next

mriem

132 posts
mriem

And we have moved! Blog

Posted by mriem Jul 4, 2015
And we have moved to https://www.manorrock.com/blog/  
mriem

Glassfish is not dead Blog

Posted by mriem May 12, 2015
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog You might have heard some folks in the JavaEE community scream "Glassfish is dead!" As I work on 2 technologies that are going to end up in JavaEE 8 I can say that for me that is certainly not the case. Certainly we do not do a lot of "official" releases of the RI implementation of JavaEE, but does that mean it is dead? Not in the slightest! For Mojarra and Ozark we run integration builds using the daily builds of Glassfish! Do I see a lot of breakage running against daily builds? No! So if you want a more recent "release" of Glassfish just use a daily build. After all what is a version number? You need 4.x or can it just be 4.1.YYYYMMDDHHSS ;) See http://download.java.net/glassfish/4.1/nightly/ Enjoy!  
mriem

Going back in memory lane Blog

Posted by mriem May 11, 2015
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog When writing an article about HtmlUnit and Maven integration testing I never expected that article to become as popular as it has. Most of my blog entries have a modest number of reads, but apparently HtmlUnit integration testing is popular enough to warrant 11,109 reads as of today. For a technical blog I consider that a good number ;) For the original blog entry, see https://weblogs.java.net/blog/mriem/archive/2011/12/13/htmlunit-and-maven-integration-testing Enjoy!  
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog Software is an interesting thing. We currently live in a very fast paced society where changes seem to come and go. However that is really only true for consumer electronics. Most systems that consumers are hardly aware of run stacks that are a couple to several years old and for those it is not economical to change at the rate consumer electronics does. Mojarra is a piece in such a stack. As part of our day job we have to maintain a large set of code lines for our customer base. If it sometimes looks that we are not moving forward fast enough just imagine we would have to support your phone for 10 years, sounds crazy right? Well for enterprise grade software that is the reality. Is that bad? Certainly not. Just keep it in mind ;) So while we keep innovating Mojarra we also have to keep maintaining your older stack. And thus we have to maintain our own stack so we can test Mojarra itself. As part of a large migration / update we are now happy to report that the several older test pieces of the Mojarra build are now all in the same Maven build structure. To put it in perspective this is the culmination of work that was started in 2012. With this all in place we hope we can be more agile in responding to issues coming from our customers and innovating Mojarra going forward. For those that want to contribute to Mojarra, please ping me and I'll explain it in more detail. Enjoy!  
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog The JavaEE 8 process is underway and JSF 2.3 is making progress. We have just released our 2nd milestone. See https://javaserverfaces.java.net/2.3/releasenotes.html for the release notes Download it from https://javaserverfaces.java.net/2.3/download.html Enjoy!  
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog Now that both JSRs are in full swing I am going to offer you all a bit of a different perspective between the 2 technologies. As I have stated before I view them both complementary to each other! I want to talk a bit about the actual work of doing the JSRs themselves. As part of the JSR we deliver a reference implementation, but in reality does the work stop there? No, it surely does not. For JSF we have years of work after the completion of any of its JSRs. So one part is working on a new JSR cycle. But in reality the buck does not stop there. I am talking about the nitty gritty of maintenance! I have now been involved in maintaining the Oracle implementation of JSF, named Mojarra since December 2011. What have I learned? Maintaining a piece of software that is backed by a specification is HARD. It by no means is boring, nor is it NOT challenging. Quite the contrary because we have to deliver fixes that stay within the confines of the specification it is at times quite challenging. Now offset this to the work that we are currently doing with the MVC specification. Is the MVC specification HARD? Yes, it is too! Weird huh? You would think writing a specification from scratch is easy as we have a clean slate. Well, because I have been involved in maintaining Mojarra whenever I look at the features we might or might not include in Ozark (the MVC reference implementation) one of the questions I ask myself is "Is there a potential for a lot of maintenance on this feature?". E.g in Ozark we have a SPI so people can plug in new ViewEngines. And we have had external contributors delivering some ViewEngines (a BIG thanks goes out to them). The question came up whether or not we should include them in the reference implementation. Since we simply cannot support all we opted for making the contributed ViewEngines community supported extensions and keep the 2 ViewEngines officially supported by Ozark to be JSP and Facelets. Why? Well, both of those are also EE specifications! Anyway, when you think about the JavaEE process and you wonder why sometimes things seem to go a bit slow, think about how long this software sticks around and that it has to meet the bar of TCK testing for every patch, bug fix or enhancement. I hope you enjoyed a look at this perspective. Note of course this is MY perspective on things ;) Enjoy!  
mriem

MVC JSR 1.0 Snapshots Blog

Posted by mriem Feb 18, 2015
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog The MVC JSR is progressing nicely and we have started publishing SNAPSHOT builds. If you want to try them out grab the API JAR from https://maven.java.net/content/repositories/snapshots/javax/mvc/javax.mvc-api/ and the Implementation JAR from https://maven.java.net/content/repositories/snapshots/com/oracle/ozark/1.0-SNAPSHOT/ For some samples see the test directory of the Git repo at it://java.net/ozark~sources Let us know what you think! Enjoy!  
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog Just like the previous blog entry "JSF 2.3 Using a CDI managed Converter" you can now do the same thing with Validators. So how does that look in code? 
  @FacesValidator(value = "myValidator", managed = true)
  public class MyValidator implements Validator {

     @Inject
     MyModel model;
    ..
  }
Note in this example the Validator would be a @RequestScoped bean as we did not state what CDI scope needs to manage it. You can use any other scope available to CDI. Beneath the covers we do not save the actual Validator instance into the view state, but we save the value "myValidator" so upon state restore we can ask CDI for the instance. And since we now have CDI managing the Validator you can also do @Inject into the Validator. Enjoy!  
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog Although a converter is considered an attached object (part of the view state) commonly people ask support for CDI injection into a converter. Since we did not want to upset the original contract of what a converter is we had to look at how we can best support the requested use case. We already had an annotation (@FacesConverter) that was being used to define a converter programmatically. To facilitate the use case we decided to add an additional attribute (managed) that states whether or not the Converter in question needs to be managed by CDI. So how does that look in code? 
  @FacesConverter(value = "myConverter", managed = true)
  public class MyConverter implements Converter {
    ..
  }
Note in this example the Converter would be a @RequestScoped bean as we did not state what CDI scope needs to manage it. You can use any other scope available to CDI. Beneath the covers we do not save the actual Converter instance into the view state, but we save the value "myConverter" so upon state restore we can ask CDI for the instance. And voila Converters can now be CDI managed! Enjoy!  
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog And it is tutorial time! Where are the JavaEE tutorials for each of the JavaEE versions?  Enjoy!  
mriem

Happy New Year! Blog

Posted by mriem Jan 1, 2015
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog Happy New Year to all! Enjoy!  
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog As we are working towards our first JSF 2.3 milestone release I want to tell everyone once it is out please start testing. With your help we are able to catch so much more before we ship. This is why we are going to be doing milestone releases. So once the first one is out try it out! I hope you all will make testing your JSF application with JSF 2.3 a New Years resolution! Enjoy!  
mriem

MVC and Adopt a JSR Blog

Posted by mriem Dec 19, 2014
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog Today I participated in a phone call on Adopt-a-JSR for the MVC 1.0 specification. While we do not have a whole lot of things that can be worked upon by a JUG at the moment I do want to point out that once we start publishing SNAPSHOT releases and milestones we will be looking forward to your contributions! I will tweet and blog about that day and hopefully it will be soon, but as I also stressed in the phone call at the moment we are still in discussion mode on the MVC specification mailinglist (which is to be expected as we are working towards a first ever release). So please hang in there and keep an eye out for the big announcement. Enjoy!  
mriem

JavaEE Tip #6 - Resources Blog

Posted by mriem Dec 18, 2014
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog The @Resources annotation makes it possible to define resources that you are going to lookup at runtime. The example describes a way to lookup a datasource that is mentioned in the @Resources annotation on the class.   @Resources(value={ @Resource(name="ShoppingCartDB", type=javax.sql.DataSource), @Resource(name="ShoppingCartMail", type=javax.mail.Session) }) @Stateful public class ShoppingCartBean { public List getItems() { DataSource shoppingCartDB = (DataSource) ctx.lookup("ShoppingCartDB"); Connection conn = shoppingCartDB.getConnection(): return null; } } Enjoy!  
mriem

JavaEE Tip #5 - Resource Blog

Posted by mriem Dec 14, 2014
Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog With the @Resource annotation you define the resource you want to inject. Note this annotation is an older style annotation. Going forward the recommendation is to use the CDI @Inject annotation. In code @Resource UserTransaction utx; Enjoy!  

Filter Blog

By date: