The Journey of OpenJDK 6 into Fedora, EPEL, and freedom - podcast with Tom Fitzsimmons and Patrick Macdonald

Posted on 2008-05-13 14:42:19.0 by Karsten Wade [ View original post ]

The first morning of JavaOne was a great serendipitous event. How often does something fall into place like this: I saw Barton George , who looks after Sun’s relationships with Linux communities, and we decided to cook up a podcast about OpenJDK 6 in Fedora 9 . As we walked to the recording room, I commented that it would be great if we could get Tom Fitzsimmons , too. Not two beats later, we rounded a corner, and there stood Tom with Patrick Macdonald. Of course they were available and happy to record with us, and away we went.

Hear Barton (and a little bit of me) interview Tom and Patrick about the journey of OpenJDK and IcedTea : OGG and MP3

The discussion covered the history of making a 100% free and open source runtime in Fedora from the initial Java open source code, which itself was 96% of a complete and self-building JDK. This remaining 4% was filled with components from GNU Classpath by the IcedTea team. The term “IcedTea” came from the package name used because, at that time, Fedora didn’t have a trademark license to use “OpenJDK”. Of the GNU Classpath code used, some if it ended up completing the circle to be included in OpenJDK. Based on relationships made at FOSDEM 2007, the team from Fedora/Red Hat were able to work with folks from Sun and other places to do work in the community in advance of resolving the remaining 4%, and do it in a way that could be more easily folded into OpenJDK.

What is riveting about this story is the speed and quality of the outcome that is clearly due to the open source methodology used. By opening all the code that they could, Sun made it possible for others to fill the gaps Sun could not immediately fill. By working closely throughout that process, all of the open source code was used and tested in the community. Sun had time to choose the right license so the code could be merged. If Sun had waited until they could open all the code, we would have lost an entire year of development (at least.)

Now that OpenJDK 6 is available in EPEL 5 for Red Hat Enterprise Linux 5 , it is only a matter of time before it gets certified to appear in an update. This is being worked on by Keith Seitz and Mark Wielaard , who have “not many” test suites to complete to be ready to pass the TCK. Once that is done, the implementation can be called “Java compliant”, which is an important step to being ready for an Enterprise Linux 5.x update.

Listen to the audio to get all the details, and check out Barton’s blog entry for his viewpoint.

---

JBoss Enterprise SOA Platform Deep Dive Webinar

Posted on 2008-05-13 11:03:11.0 by Pierre Fricke [ View original post ]

Burr Sutter presents a great JBoss Enterprise SOA Platform Deep Dive Webinar !

This is the recording from April, 2008 with lots of detailed information and demos.

---

JBoss Enterprise SOA Platform with ActiveEndpoints Active VOS (BPEL) demo

Posted on 2008-05-13 10:19:55.0 by Pierre Fricke [ View original post ]

Our partners at ActiveEndpoints have created an interesting and educational demo showing how to use their ActiveVOS (BPEL) with JBoss Enterprise SOA Platform to solve business process challenges and improve business execution.

---

JBoss Portal 2.6.5.GA released

Posted on 2008-05-13 08:29:00.0 by noreply@blogger.com (Thomas Heute) [ View original post ]

The latest minor release of JBoss Portal has just been released.
This is a bug fix release, here is the full release note.
Grab it while it's hot and don't hesitate to report issues in the forums .

Thanks for the feedbacks we got on previous releases !

---

Ajax4jsf - a chat about the RichFaces framework with Alexander Smirnov

Posted on 2008-05-12 20:24:35.0 by Karsten Wade [ View original post ]

At the JBoss booth at JavaOne 2008, I spoke with RichFaces developer Alexander Smirnov (OGG , MP3 .) Alexander is the founder of the Ajax4jsf project, which he started as a personal side effort. It grew out of his interest in JSF and was originally run as a stand alone, self-hosted project.

As he developed Ajax4jsf, Alexander began working with the MyFaces community, and started communicating more with the larger JSF community. He moved the project to SourceForge at the suggestion of RichFaces lead developer Sergey Smirnov (no relation.) Exadel began developing the RichFaces JSF components library and Alexander joined the project as a framework background developer.

At the time it moved to java.net, Ajax4jsf had grown more useful when integrated with the RichFaces component library. RichFaces, however, was still not open source. The combined projects came to the attention of JBoss, which contracted with Exadel to open source both projects as JBoss projects. These were recently combined into a single project under the RichFaces name, available through JBoss.org . (RichFaces is combined with the JBoss Tools Eclipse-based developer environment to make up the JBoss Developer Studio subscription offering.)

Current activity for the RichFaces project includes a focus on building RichFaces functionality within JBoss Portlet Bridge . JBoss Portlet Bridge implements JSR-301 to provide support for not only JSF running in a portal, but also Seam and RichFaces.

Joining forces with JBoss has brought significantly more usage, ten times or more in terms of downloads. In particular, Alexander says there is an obvious increase in forum questions and discussions. In terms of attracting contributors, there are currently very few code contributions from the community outside of Exadel and JBoss. Alexander and Sergey describe the development process for the RichFaces team as being structured with a well-oiled process, which creates a higher barrier of entry for people outside of the team. As early ways to bring in external contributors, there are current needs for testing, defining future requirements, and requesting features and enhancements.

For the future roadmap of RichFaces, Alexander says that the next step is toward semantic web technologies.

---

RichFaces/Ajax4jsf project discussion with Alexander Smirnov, JBoss Booth, JavaOne 2008

Posted on 2008-05-12 19:06:23.0 by JBoss.ORG Team [ View original post ]

Enclosure:http://www.jboss.org/files/jbosslabs/podcasts/Alexander_Smirnov-JBoss_RichFaces-JavaOne-2008.ogg

Ajax4jsf project lead Alexander Smirnov spends a few minutes with JBoss.org /Dev Fu to discuss the history and future of Ajax4jsf. MP3 format is also available.

---

RichFaces/Ajax4jsf project discussion with Alexander Smirnov, JBoss Booth, JavaOne 2008

Posted on 2008-05-12 18:54:42.0 by JBoss.ORG Team [ View original post ]

Enclosure:http://www.jboss.org/files/jbosslabs/podcasts/Alexander_Smirnov-JBoss_RichFaces-JavaOne-2008.mp3

Ajax4jsf project lead Alexander Smirnov spends a few minutes with JBoss.org /Dev Fu to discuss the history and future of Ajax4jsf. OGG format is also available.

---

Writing a RHQ plugin Part 2

Posted on 2008-05-09 15:56:00.0 by Heiko W. Rupp [ View original post ]

In the last post I showed the general architecture of RHQ and where plugins live. So we can now start writing one.

The scenario revisited

Our plugin should be able to connect to a http server, issue a HEAD request on the base url (e.g.
http://localhost/) and return the http return code as trait and the time it took as numeric data (see below).



To make things easier for the purpose of this series of postings, we will have the agent running on the machine the RHQ server lives on and we will just try to get data from the Servers http connector at port 7080 (the default port).

What do we need ?

In order to write our plugin we basically need three things

• A plugin descriptor. This contains metadata about the plugin: which metrics should be collected, what operations does it support etc.


• A discovery component. This part discovers the actual resource(s) and delivers them to the Inventory.


• A plugin component. This component executes operations and gathers the measurement data etc.

So lets have a look into those three parts.

Plugin descriptor

The plugin descriptor is described by an XML Schema that you can find in svn . The basic structure is as follows:




(Click for pdf version)

The desciptor consists of a few sections. First you can express dependencies to other plugins. This is allows reuse of existing plugins and is useful when you e.g. want to write a plugin that itself needs the JMX plugin, so that it can do its work.

The next are a row of platform/server/service sections. Each of those can have the same (XML-)content as the platform that is shown as an example - they are all of the same (XML-) data type (as a platform/server/service) as each is a kind of resource type, as you already know from the first part.

Example:

<service name="CheckHttp">

   <metric property="responseTime"

           description="How long did it take to connect"

           displayType="Summary"

           displayName="Time to get the response"

           units="ms"

   />

</service>

The name of a <service> and the other ResourceTypes (platform, server) must be unique for a plugin. So it is not allowed to have two services named "CheckHttp" within our example plugin, but you could write a Tomcat5 and a separate Tomcat6 plugin that both have a service with the name "connector".

For the start we are especially interested in one of the sub elements: metric for our example plugin, so I will describe this here in a little more detail. For all other tags refer to the XML Schema that has a lot of comments.

Metric

This is a simple element with a bunch of attributes and no child tags. You have already seen an example above.
Attributes of it are:

property: name of this metric. Can be obtained in the code via getName()

• description: A human readable description of the metric


• displayName: The name that gets displayed


• dataType: Type of metric (numeric / trait /...)


• units: The measurement units for numerical dataType


• displayType: if set to "summary", the metric will show at the indicator charts and collected by default


• defaultOn: Shall this metric collected by default


• measurementType: what characteristics do the numerical values have (trends up, trends down, dynamic). The system will for trends* metrics, automatically create additional per minute metrics.

For the sample plugin we will use a metric with numerical dataType for the response time and a dataType of trait for the Status code. Trait s are meant to be data values that only rarely change like OS version, IP Address of an ethernet interface or the hostname. RHQ is intelligent enough to only store changed traits to conserve space.

Discovery component

The discovery component will be called by the InventoryManager in the agent to discover resources. This can be done by a process table scan (e.g. for the Postgres plugin) or by any other means (if your plugin wants to look for JMX-based resources, then it can just query the MBeanServer. Well, actually there is a JMX-Plugin that can do that for you in clever ways).

The most important thing here is that the Discovery component must return the same unique key each time for the same resource .

The DiscoveryComponent needs to implement org.rhq.core.pluginapi.inventory.ResourceDiscoveryComponent and you need to implement discoverResources() .
The usual code block that you will see in discoverResources() is:

  Set<DiscoveredResourceDetails> result = new HashSet<DiscoveredResourceDetails>();

  for ( ... ) {

     ...

     DiscoveredResourceDetails detail = new DiscoveredResourceDetails(

         context.getResourceType(),

         uniqueResourceKey,

         resourceName,

         resourceVersion,

         description,

         configuration, // can be null if no confi

         processInfo); 

 result.add(detail);

  }

  return result;

Basically the context passed in gives you a lot of information, that you can use to discover the resource and create a DiscoveredResourceDetails object per discovered resource. The list of result objects is then returned to the caller. Simple - eh?

Plugin component

The plugin component is the part of the plugin that does the work after the discovery has finished.
For each of the "basic functions" in the plugin descriptor, it needs to implement an appropriate Facet :

Descriptor element	Facet
<metric>	MeasurementFacet
<operation>	OperationFacet
..	...

Each Facet has its own methods to implement. In the case of the MeasurementFacet this is e.g. getValues(MeasurementReport report, Set metrics) . The report passed in is where you add your results. The metrics is a list of metrics for which data should be gathered. This can be all ouf your definied <metric>s at once or only a few of them - this depends on the schedules the user configured in the GUI.

Ok, that's it for now. In the next post we will do some coding and get our plugin to work.