Ed Burns's Blog

Community Archives

I have made an impressively insignificant contribution to Wikipedia

Much has been said and written about Wikipedia. Many people contribute many hours to this noble cause. I, on the other hand, have contributed one tiny factoid to this vast web 2.0 body of knowledge.

• John Bonham's Drum Pedal Squeaks on Ten Years Gone

I slept well that night, after making that contribution, knowing that I had made the world 0.00000000000000000000001% better.

irc followup: let's try JXTA

To follow up to my previous blog about the desire for irc.java.net, I'd like to talk about using Project JXTA in the interim (and perhaps indefinately, if people like it) to fill the gap.

Shortly after posting the above blog, I was contacted by James Todd about the possibility of using MyJXTA as a distributed chat service. I tried it out, and it seems to fit the bill pretty well.

So, I've created a public jxta group called jsfaces. You can join by using Java WebStart and clicking on this link.

In my opinion, the number one advantage JXTA has over old school IRC is the ability to easily tunnel through HTTP using the standard java control panel proxy settings. In this way companies like Oracle, with firewalls that only permit HTTP to traverse, can participate in the chat.

I hope to see you all in the jsfaces chat room!

In any case, please continue to vote for irc.java.net, even if you try out JXTA.

Let's hear it for irc.java.net

Is it just me or do you also feel that java.net will never be a leading open source community without having its own irc server? Mozilla has one, Netbeans uses freenode, the list goes on and on. It's just a great way to do realtime collaboration. For example, in my case if we had a channel for JavaServer Faces, users could get in touch with developers right away. Also, if we had one for the JavaServer Faces EG, expert group members could chat about things in real time and resolve issues faster.

I filed a bug on this at java.net, which was closed due to lack of interest. Please vote for this bug!:

https://java-net.dev.java.net/issues/show_bug.cgi?id=149

TSSJS Rod Johnson Keynote

Rod Johnson

  - Agile J2EE has saved the J2EE platform from destroying itself via
    its own best practices (blueprints).

  - AOP 

    Not growing as fast as he expected, but it will continue to grow

    AspectJ 5.0 will be the definitive AOP framework going forward

    Standardization?

      Hard to see the benefit now

    JCP standardization not appropriate for AOP.  AOP is not
    language-specific.

    Proxy-based AOP: a transitional technology

    Implications of AOP for app servers

    - We'll see an evolution from a monolithic container to a service
      integration point.  I think he's saying the app server is being
      commoditized.

    Technologies to watch

      IoC/Dependency injection

      TDD

      O-R mapping.  

      Post struts 1.x web technology

      Value add web technologies

        Struts 2.0 is moving into workflow

        Beehive

        Spring is adding web flow technology

     Rich Client

     Technical skills to acquire

       Frameworks/methodologies

       Ability to set and ensure project direction

       Offshoring: it's coming, if you know to leverage, you'll have a
       job

TSSJS Caesar's Palace Party notes

Introducing Jayashri Visvanathan

After leading the JavaServer Faces implementation team through our 1.0 release I deciced to spend more time on developing the specification itself, and have handed the leadership over to the ever-so-capable Jayashri Visvanathan. Jayashri was a key contributor to the project during 1.0, and has lead the team through the 1.1 and subsequent releases. I'm devoting this blog to giving the community a chance to get to know Jayashri better, and to give her a chance to share her vision for the future of the JavaServer Faces project.

Ed Burns: How do you think the Java Enterprise community will benefit from having javaserverfaces as an open development project?

Jayashri Visvanathan: Thanks for the introduction as well as for your vote of confidence. Following are some of the important benefits of open development.

• One of the major concerns of the community has been that they have no knowledge of what features/bugs would be addressed in the next release. With open development, they have access to issues list for the current release as well as for the future releases.

• They get to file issues and track any updates to that issue. If they are subscribed to the dev@javaserverfaces.dev.java.net alias, they can follow discussions about various issues including any code changes.

• They are able to get access to the bug fixes/features on a day to day basis. Currently we don't have nightly builds set up but it will be available shortly.

• They have access to latest source code. Once the JDL license for JSF is available, they will be able to modify and redistribute the binaries.

To summarize, they get to fully participate in the development of JSF, as an observer, code contributor or as a committer.

EB: What are your priorities for the project over the next 6 months?

JV: Here's an unprioritized short list of some things I'd like to do

• Make nightly builds available.

• Set up cruise control so that it can viewed externally. For those who are not aware, cruise control defines a build cycle determines if a build is necessary, if so builds, runs tests, creates a log file, and sends notifications. Right now, this is running on a Sun system and we would like to make it available to everyone.

• Start accepting external contributions. To make this happen we are looking at how to make it as easy as possible for external committers to run the test suites.

• Continue to focus on improving the performance of the RI in order to make it production quality.

• Build a community of developers who are committed to increasing the quality of Sun's JavaServer Faces implementation.

EB: How do you feel about competing with other JavaServer Faces implementations? Where do you see your implementation excelling?

JV:JSF RI tracks the spec very closely serving as a proof of concept for the JSF specification. In addition, thanks to Ryan Lubke, our TCK Engineer, the tests are being run on a continous basis to catch any spec violations early and often. Our goal is to make the RI production quality and highly scalable.

EB: How do you plan to address feature requests and bug reports?

JV: Bugs will be evaluated within a week. If the bug is critical enough or is show stopper, we would make every effort to address it immediately. I would like to take this opportunity to encourage everyone to file issues for all bugs and any feature requests they have. To help us to quickly fix the bug, be sure to include as much information with your report as possible such as a test case, your platform, version numbers and steps to reproduce the problem.

EB: What can you tell us about your process for accepting contributors to the project?

JV: We are currently accepting code contributions/patches from the community. Detailed guidelines for submitting patches is in FAQ. In order for your patch to be accepted quickly, please attach a test case. JSF team follows test first development & code review process strictly, so if a patch doesn't have a test case, we would have to create/update an existing test for it which would delay the acceptance of your patch. Contributors who give frequent and valuable contributions can become a committer if they desire. Again,the FAQ details the JSF code development process.

EB: What do you see as some of the challenges this project may face?

JV: Our challenge would be make the RI highly scalable and of production quality in addition to keeping up with the latest spec revisions. With help from the community, its a definite possibility.

EB: How will you judge the success of the project?

JV: Based on community's feedback and their participation. JSF community has always been very vocal about pointing good and bad things about the specification as well as the RI and I hope they continue to do that and thats key to success of this project.

With that, I would like to thank you once again for introducing me and I look to forward to working with the Java Enterprise community.

Welcome to the JavaServer (TM) Faces Implementation Project!

Hello, and welcome to my first blog on java.net. In spite of all the hype about blogging lately, I was still hesitant to jump into the blogging universe until I had something to say, and today I do: Welcome!

People have been requesting that Sun release the source code of its implementation of JavaServer(TM) Faces Technology for several years, and Sun's answer has been that doing so is under review. I won't go into the reasons for the length of the review process, but I'm happy to announce that it's finally complete. We have created an open development project on java.net to host the continuing development of Sun's JavaServer Faces implementation. All previously internal development will be done in this project; there is no private source tree that we really use. In other words, this project is not just for show. Please read the FAQ for answers to such pressing questions as "how do I get and build the source".

You'll note that I didn't use the term "open source", but rather, "open development". We're doing so out of respect for the rigorous definition of the term supplied by the Open Source Definition (OSD). I'm not a lawyer, and I can't tell you where the Java Research License, which we're using for our project, stands with respect to the OSD. I'll leave that to someone who doesn't write code!

In any case, as with any open development project, there are many levels of participation. You can file bugs so we know about them and can get the fixes to you as quickly as possible. You could simply grab our regular builds to check if your pet bug has been fixed. You can browse the source code to get an explanation of the behavior you're wondering about. You can, also (my favorite) build the code yourself and run it in a debugger for the ultimate in development transparency.

Presently we are only accepting Observer role members into the project, but we plan to open the project up to committers on a case by case basis once trust is established that our development processes will be followed.

So what are these processes? We'll have more detail in the FAQ but here's the idea. All the code in the javaserverfaces was developed using Test Driven Development. Each checkin must include either a new test, or a modification to an existing test to prove that the new code works as expected. Before checkin, each developer's workspace must successfully execute all automated tests, as well as have code review and approval from another developer. We employ the usual suspects to make this happen: ant, junit, cactus, and htmlunit. Heavyweight? Perhaps, but when you're testing resources are so taxed that they can't spend as much time as you'd like with your project, these measures are well warranted. I feel that our commitment to code review and test driven development has contributed significantly to the quality of the project, and helped to reduce the bug introduction rate.

To wrap it up, I'd like to share what we hope to gain from doing open development on javaserverfaces. This project aims to:

• be the most complete implementation of the specification.

• have a fast turn-around time for getting bug fixes into the hands of users.

• build a community of developers who are committed to increasing the quality of Sun's JavaServer Faces implementation.

• demonstrate uncompromising commitment to test-first development and code review for all code coming into the project.

This work is licensed under a Creative Commons License.