 |
Search |
 |
||||
|
edburns's BlogMojarra 1.2_15 releasedPosted by edburns on July 20, 2010 at 11:04 AM PDT
With very little pomp and only extenuating circumstance, we are releasing Mojarra 1.2_15. This release does have most of the performance fixes I mentioned in this blog post, but only for those running JSF 1.2. Technorati Tags:edburns »
Related Topics >>
Blogs Comments
Comments are listed in date ascending order (oldest first)
Performance boost
Submitted by edburns on Thu, 2010-07-22 14:34.
Stevan Malesivic, from Oracle's performance group, had this to say: SM> some internal PSR test s were done on JSF1.2_15 vs. JSF 1.2_09 using SM> WebCenter/Portlets test case and JSF1.2_15 shows 7% better throughout
JSF 2.1 Build 01 integrated into GlassFish nightlyPosted by edburns on July 14, 2010 at 8:05 AM PDT
JSF 2.1 Build 01 integrateg into GlassFish nightlyThis quick entry announces that we've started work on JSF 2.1 in earnest. Soon after Oracle acquired Sun, Blake Sullivan and Andy Schwartz, Oracle UI Technologies Architectects from the ADF Faces team, donated a significant patch of performance enhancement work to the Mojarra project. This work initially went into JSF 1.2 and will be in the upcoming Mojarra 1.2_15 release. I have recently completed integrating it into the HEAD branch of Mojarra for JSF 2.1. The easiest way to try it out is to grab a GlassFish 3.1 nightly build from 14 July or later.
If you're interested in the specific fixes, this java.net query shows them up. Technorati Tags:edburns »
Comments
Comments are listed in date ascending order (oldest first)
what about version 2.0.x
Submitted by frank_langelage on Sat, 2010-07-24 03:25.
Will these improvements also be integrated into the 2.0.x branch?
Lean Team + Agressive Schedule = Possible Software GhettoPosted by edburns on July 9, 2010 at 9:15 AM PDT
The original Pragmatic Programmers, Andy Hunt and Dave Thomas, talk about the tragedy of the software ghetto in this 2003 interview with Bill Venners. We all know the story of how unfixed broken windows can cause a nice neighborhood to start looking like a ghetto, and how this analogy is applied to an enterprise software project. While working through my email today, I came across a management pitfall: Agressive Scheduling + Lean Team = Software Ghetto. Here's the story. My current lean team is dealing with a steady influx of bugs/issues found in the source code, while at the same time having to conform to an agressive schedule with very clearly defined priorities. If an issue doesn't fit within the priorities for the schedule, it's put on the bottom of the list. As one of the responsible engineers for Oracle's JSF implementation, Mojarra, I have committed to review and evaluate new issues on the issue tracker as quickly as possible after they come in. I try to do this as part of my email reading process. Today's issue: 1729. While using our existing automated test harness to try to reproduce the bug, I made an XML authoring error, but it took a while to diagnose because I found another bug that was masking the exception. The right thing to do would be to file an issue on this other bug and move on. However, our current agressive schedule and lean team would dictate that this issue would certainly not be addressed this calendar year, and would likely never make the cut because such little issues are never high priority enough to be judged important when crafting an agressive schedule. So, I decided to fix the exception masking issue now. Did I make the right choice? According to the management school of laser focus, schedule at all costs, probably not. According to the school of quality and ghetto avoidance, probably yes. I assert that projects that have agressive schedules with clearly defined priorities combined with a lean team to meet that schedule will tend to generate software ghettos. What do you think? Did I make the right choice? Technorati Tags:edburns »
Comments
Comments are listed in date ascending order (oldest first)
The middle path, the middle path...
Submitted by ronaldtm on Fri, 2010-07-09 13:26.
It depends on how you manage priorities.
It is like 'starvation' in concurrent programming. Having threads greater priority always have precedence over lower priority ones, leads to never executing the latter and generating an undesirable/unexpected effect. If your priorities' policy say 'priority 1 is always taken before priority 2', you will get into trouble, whatever they are. Even if priority 1 is the so called quality. If you always put quality over, say, (business) value, you'll just deliver useless zero-defect software. The same way, if you always put your schedule over quality (only worry about the schedule, and never about quality), you'll inevitably get crappy software. fleXive: CMS built on JavaEE and JSFPosted by edburns on May 18, 2010 at 7:46 AM PDT
I've known about fleXive since JSF Days 2009, when I met its lead engineer, Daniel Lichtenberger. At the time, we were trying to get them into the GlassFish partner program, but due to lack of resources, this didn't pan out. Daniel continued to work on fleXive steadily. This year, at JAX-2010, they had a booth. It's great technology, and I encourage you to check it out. Technorati Tags: edburns »
Comments
Comments are listed in date ascending order (oldest first)
JSF 2.0.3
Submitted by dyegocarmo on Wed, 2010-06-02 09:53.
Ed , exists a RELEASE date for version 2.0.3 ?
I have a terrible bug on it :(
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1696
Release date: trying for next week
Submitted by edburns on Fri, 2010-06-04 13:34.
It may not have your 1696 fix in there. I'm looking at it now.
Design Time Metadata for JSF Components Completes Early Draft ReviewPosted by edburns on May 17, 2010 at 1:07 PM PDT
JSR-276 is targeted at IDE vendors and the JSF component library vendors who depend on them for exposing their components to developers. The idea of JSR-276 is to let JSF component library vendors provide a far richer set of descriptive data about their components so that JSR-276 compliant tools can expose that data to the users. Examples of such data include:
There are many more exciting metadata elements in JSR-276. Check itb out yourself at <http://jcp.org/en/jsr/summary?id=276>. If lots of people show interest in this, we'll have a better chance of IDE's supporting it. Once the spec goes final, let's make a point to add issuetracker issues in the major IDEs to support it. Technorati Tags: edburns »
Comments
Comments are listed in date ascending order (oldest first)
Will the Pomodoro Technique Work for Me?Posted by edburns on May 15, 2010 at 4:34 AM PDT
I have the extreme good fortune to speak at several conferences a year, and I always grow from each one, either by taking in useful content, or by meeting interesting people. This week I made my first trip to Poland, to speak at GeeCON 2010. As usual, I decided to re-invent my JSF presentation and didn't start the effort in earnest until far to late in the process. Though I was happy with the result, I missed seeing Staffan Nöteberg's presentation on the “Pomodoro Technique”. Staffan’s abstract read, You have so much you need to accomplish today. Your list is a mile long and you find yourself getting interrupted every other minute. You'd like to tell everyone to leave you alone, but most of the interruptions are coming from you! You think of a phone call you need to make or a web site you need to check and before you know it you're answering email, checking twitter, and finding a million other things to occupy your time. You need to focus - really focus. The Pomodoro Technique puts you back in charge of your day. As a practicing software professional, and having written a book that explored this topic from another angle myself, I really wanted to see the talk. However, priorities are priorities, and I wanted to have all new content for my JSF2 talk. As it turns out, prioritization is at the heart of the Pomodoro Technique, so I was already on the mark. Later that evening, I had the opportunity to have dinner with Staffan and he and I exchanged books. Here's why I’m so excited about reading this book. It explicitly acknowledges that humans can only do one thing at a time, more poetically put as, “You can’t dance at two weddings with one rear end.” I expect that my existing practice of using the Franklin Planner, combined with Pomodoro, will help me get more done and mitigate the effects of distractions. In any case, this is the first self help book I’ve been excited about in a long time, so that much is a win. [Yes, I wrote this in the span of one Pomodoro.] »
Comments
Comments are listed in date ascending order (oldest first)
New process for subscribing/unsubscribing to jsr-314-open@jcp.orgPosted by edburns on March 19, 2010 at 12:23 PM PDT
My last blog entry about JSR-314-OPEN@JCP.ORG was over a year ago. This list is the official Expert Group (EG) mailing list on which the development of the JSR-314 specification (JSF 2.0) is discussed. The information on how to subscribe/unsubscribe to this list changed in June 2010, but I haven't updated any existing information or blogged any new information about it. This is the overdue blog entry! The new way to subscribe/unsubscribe to JSR-314-OPEN@JCP.ORG is to
send mail to < To subscribe to the list in read-only mode make the subject of the email be "subscribe jsr-314-open". To unsubscribe from the list, make the subject of the email be "unsubscribe jsr-314-open". Only official EG members and Extended EG members may post to the list. If you want to become an Extended EG member the best way to do it is to make yourself known to one of the existing EG members who can petition the EG for you to be added as an Extended EG member. In general, you'll need a good reason for being accepted to the Extended EG. Having lots of experience with and passion for JSF certainly helps. Finally, there will very likely be at least one more change to how one subscribes to JSR-314-OPEN, but this change is waiting on the resolution larger issues with the JCP itself. Technorati Tags: edburns »
Comments
Comments are listed in date ascending order (oldest first)
The perils of "There's more than one way to do it"Posted by edburns on March 3, 2010 at 1:55 PM PST
At the very beginning of my full time programmer career, when I worked at Silicon Graphics, Larry Wall and Randal Schwartz gave a brown bag session about their now legendary camel book. Naturally, I had them sign my copy, the front page of which I proudly display at left. Notice the “There’s More Than One Way To Do It!” stamp at the top. For better or worse, Perl is famous for this property. Less famous (or perhaps even infamous) for having more than one way to do it is JSF. At the JSFdays conference last week, I was having lunch with Imre Oßwald and the topic turned to JSF deployments in large projects. Imre mentioned that his project was bitten by the fact that there was more than one way to do it in JSF. If you give developers more than one way to do something, they'll take advantage of that capability. But, in a large project with many developers, this can lead to confusion and unmaintainability. The simplest remedy is to establish firm and strong conventions for how to do things for which there is more than one way to do it. Of course, this is easier said than done, but I believe, as do Wall and Schwartz, that having more than one way to do it is generally an asset rather than a liability.
»
Comments
Comments are listed in date ascending order (oldest first)
Hey, that looks familar
Submitted by randalschwartz on Thu, 2010-03-04 10:19.
Programming Perl, First Edition. My first book with my name on the cover (although I had ghost-written a dozen books before that).
Do you have a google alert?
Submitted by edburns on Thu, 2010-03-04 12:27.
Thanks for commenting! I'd love to know how you were alerted of the existence of this post. I'm quite certain that you don't manually subscribe to my blog entry, because, after all, you wrote the camel book.
You don't by any chance remember that session at SGI in Mountain View in 1995, do you?
The magic of Kibo
Submitted by randalschwartz on Sat, 2010-04-03 08:57.
Yes, I have custom RSS feeds that watch for my name and the names of my books and FLOSS Weekly using the power of Google, which I read in Google Reader.
I taught a lot at SGI during the first web boom, so I don't remember the *specific* session, but I remember being there. Oddly enough, my "Google Tech Talk" on git was done about 50 feet from where I used to teach at SGI, since Google HQ is the former SGI buildings.
There will always be more than one way to do it
Submitted by breilly on Wed, 2010-04-14 11:27.
The key is to make the preferred way for the majority of cases also be the most obvious way... to both the author and the reader.
Be flexible, or die!
Submitted by edrandall on Wed, 2010-05-05 01:55.
Having "more that one way to do it" gives the system an inherent advantage, perhaps one of the reasons for the longevity of PERL.
If product A provides "only one way to do it", it can become inherently harder to integrate A to work with C and D.
If B on the other hand is flexible, there's a good chance I can work around any issues,
at least I have more options and tactics available to succeed getting the whole system up and running.
So I'll choose B over A any day. It's genetically stronger.
This is perhaps one of the problematic consequences of "programming by convention" that is often overlooked.
It might get you up-and-running with something impressive to show quite early on, but try and do anything that
conflicts with those conventions and by golly you're in for a hard time!
Trustwave SpiderLabs sets sights on Mojarra, MyFacesPosted by edburns on January 31, 2010 at 1:11 PM PST
I received an email from core Mojarra team member Jim Driscoll, who was inexplicably laid off from Sun after its recent acquisition by Oracle, about a talk at next week’s BlackHat Conference in Arlington, VA, U.S.A.. Jim pointed out that two security luminaries from the elite SpiderLabs team from Trustwave are giving a talk at BlackHat about view state security, specifically focusing on Mojarra and MyFaces. Cursory research on the talk found two articles: one by Kelly Jackson Higgins at DarkReading, and another (which appears to be based on the first) at SC Magazine. The talk will be given by David Byrne (the guy who released grendel, not the guy from Talking Heads), and Rohini Sulatycki. For my money, the most important quote in the former article is, “There’s no patch to fix these flaws, either. ‘All developers have to do is perform a configuration change,’ he says, and encrypt view state.” I haven’t seen their presentation yet, but for Mojarra, you can put lines 16 - 24 of the following web.xml into your web.xml to ensure that client state will be encrypted.
A zipped netbeans project that does this is available at <http://mediacast.sun.com/users/edburns00/media/TestClientStatePassword.zip> »
Comments
Comments are listed in date ascending order (oldest first)
Yes, this is known problem,
Submitted by alexsmirnov on Sun, 2010-01-31 20:18.
Yes, this is known problem, and that is why both JSF implementations have the view state encryption feature.
Another hole has been introduced by JSF 2.0 AJAX feature there list of components to execute at form submission can be sent from client, so attacker has ability to change application logic ( bypass validation of some fields, for example ). There is no simple way to protect application from such vulnerability except additional checks in application code. That is why I've always been against "execute" or "update" parameters in AJAX request.
Config for Apache MyFaces
Submitted by mwessendorf on Mon, 2010-02-01 15:24.
Hello Ed,
similar to Mojarra you can avoid this on Apache MyFaces as well. There are some options documented here.
http://wiki.apache.org/myfaces/Secure_Your_Application -Matthias A Response to Peter Thomas's JSF Critical ScreedPosted by edburns on January 22, 2010 at 5:25 PM PST
Reference to correct post at <http://weblogs.java.net/blog/edburns/archive/2010/01/22/analysis-peter-thomass-jsf-critical-rant>. »
Related Topics >>
Java Enterprise Web Applications Comments
Comments are listed in date ascending order (oldest first)
|
||||
|
|||||
|
Performance severity?