Enterprise Java Beans (EJB) 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0’s goals are to simplify development, facilitate test driven development, and focus more on writing plain old java objects (POJOs) rather than on complex EJB APIs. EJB 3.0 has fully embraced Java Annotations introduced in JDK 5.0 and also simplifies the API for CMP entity beans by using Hibernate as the EJB 3.0 Java Persistence engine.

Usable outside of the container!

The EJB 3.0 Persistence specification allows you to use the new persistence API in plain Java applications. JBoss EJB 3.0, also gives you the ability to use Session Beans and Message Driven Beans out of the application server in standalone programs, junit tests, standalone Tomcat, and even other application servers. Download our Embeddable EJB 3.0 container or find out more information here.

The JBossMX project is the JBoss application server implementation for the Java Management Extensions technology and the core of the JBoss microkernel architecture. It is optimized for speed in the MBean server invocation bus and will support many of the advanced features such as security, transactions, MBean server federation, and fail-over.

JMX/JBOSS THE MICROKERNEL DESIGN

While most other server use JMX for, well, management, we at JBoss use it as the basis for our modularity. The full server is based on the microkernel which provides core services such as classloading and cycling as well as configuration of these and deployment of services. All of JBoss is then lego pieces, known as MBeans, that sit in the MBeanServer and communicate with each other. We are capable of independently cycling the different parts thereby achieving 24×7 stability of the codebase. This is also the reason for JBoss’ high degree of modularity. In JBoss 3.0 deploying and removing services is as simple as dropping the service.xml description file in the deploy directory or removing it from the deploy directory. Customizing JBoss is trivial. Also this microkernel design, comes with state of the art classloaders that support cycling and remote loading so you can fully install JBoss from a central webserver

The JBossMX implementation is in many parts based on the design and code discussed in the JMX: Managing J2EE with Java Management Extensions book published by SAMS.

Order a copy to support development.

Download book source code.

Active Development

JBossMX will be enhanced to support the JMX 1.2 API. We will be publishing a Functional Requirements Specification and new tasks shortly.

You can find us discussing development topics in the JMX Development Forum.

Join us now! Come on board of the JBossMX project, the microkernel infrastructure of the JBoss application server.

This document describes a rewrite of the original Tinderbox 1.0 development tool.

Tinderbox is the first program to allow developers and management to see at a glance what is currently going on in all aspects of the development process. The Tinderbox server prepares HTML pages which display the history of many different development variables. It shows at a glance the history of: whether the HEAD branch of the source code builds and passes all automated tests, who has checked code changes into the version control system, whether the source tree is open or closed and when the state of the tree last changed, what trouble tickets have been closed, notices and messages posted by the developers or project manager.

The new Tinderbox code is highly configurable and will allow you to work with many different types of version control or bug tracking systems. It is relatively easy to add new modules which work with other systems. It is also easy to configure Tinderbox to run without the displays that your organizations does not need or to run with duplicate modules if the need arises.

Here is a description of the main Tinderbox subsystems:

1. Tinderbox is an automatic build master. The build module allows an organization to dispense with the dedicated employee whose title is ‘build master’. A fleet of dedicated build machines continually run the compilations and any automated tests of the latest source code. Developers can see at a glance whether the most recent changes in the version control system will break the build of the product, break any automated style (lint) checks, cause the automated unit tests to fail or cause the code coverage of the unit tests to drop below a required minimum. These builds are not run daily as with most organizations but are run continually for immediate feedback. Each developer can monitor whether his changes break the automated build/tests and each developer can see at a glance which developer caused an problems which are being reported. The build/test logs are available at the click of a web link so that developers need not have access to the build/test machine/architecture to fix any compilation/test problems. Tinderbox allows the build organization to push back the responsibility of ensuring the code builds to the developer who just checked in the code. Anyone with a browser can see if the build failed and read what the error message was. Tinderbox does not prevent any development from occurring. Should it ever be necessary to allow development to proceed even though the tests are broken it is easy for developers to ignore the reports of failing tests and to configure Tinderbox to not display any tests which are not currently being monitored. Tinderbox does not enforce any development methodology it only displays the current ’state of development’.
2. Tinderbox displays the history of recent changes to the code stored in a Version Control system. This allows developers to see at a glance which portions of the code are being changed and who is changing the code. It is no longer necessary to configure the Version Control system to mail each developer when changes are occurring. Any developer who needs to know what is going on with the sources can see at a glance what changes were made. When the builds/tests fail it is easy to figure out what person is responsible for the problem. The person who “broke the build” is any person who did a checkin between the last good build and the broken build. This quickly narrows the possible suspects and allows for transparent accountability for any problems. After the Project Manager closes the tree for further checkins all checkins appear in a shaded color (grey) so that it is easy to desert which checkins were made after the tree was closed and see of any checkin policies have been violated.
3. Tinderbox box will soon display the trouble tickets which were closed. Since the changes in the code were likely made to fix bugs, it is convenient to have the current changes to the bug tracking system displayed on the Tinderbox pages.
4. Since the Tinderbox web pages are a centralized place for Project information there is a “Message of the Day” for managment messages and a “Notice Board” where developers can post information of interest the project. Typically the notice board is used to announce when a developer makes major changes to the source code or to confirm that a recent build failure is being fixed or backed out.

Bonsai is a really cool idea on how to “see” changes taking place during a development cycle. The original implementation was by Terry Weissman, first done in TCL, then later ported to Perl. It’s built to run against CVS using Perl, MySQL, and your favorite webserver to display checkin history, log information, diffs, and other assorted pieces of information in easy to parse HTML.

Bonsai has sort of been the red-headed step child of the Mozilla webtools, especially compared to the much more active and widely installed Bugzilla, but it’s finally starting to get some much needed love

Getting the source:

You check it out from our CVS server by doing

    cvs checkout mozilla/webtools/bonsai mozilla/webtools/registry

Please see our CVS page for information on using our CVS server. (The Tinderbox and Bonsai sources are currently only available via CVS.)

go to Project Site

JBoss community projects sit between your application code and the operating system to provide services such as persistence, transactions, messaging and clustering. Implementing this software in Java allows it to run on many different operating systems, giving you the flexibility to develop and deploy applications wherever you like. The aim is to regularly release stable versions together with documentation for use in cutting-edge application development.

Struts 2.0.11.2 comes with a security fixed version 2.0.5 of XWork, which corrects a serious vulnerability in ParametersInterceptor allowing malicious users to remotely change server side context objects. All users are strongly encouraged to upgrade to Struts 2.0.11.2.

Struts 2.0.11.2

Hibernate, like all other object/relational mapping tools, requires metadata that governs the transformation of data from one representation to the other (and vice versa). As an option, you can now use JDK 5.0 annotations for object/relational mapping with Hibernate 3.2. You can use annotations in addition to or as a replacement of XML mapping metadata.

The Hibernate Annotations package includes:

• Standardized Java Persistence and EJB 3.0 (JSR 220) object/relational mapping annotations
• Hibernate-specific extension annotations for performance optimization and special mappings

You can use Hibernate extension annotations on top of standardized Java Persistence annotations to utilize all native Hibernate features.

Requirements: At a minimum, you need JDK 5.0 and Hibernate Core, but no application server or EJB 3.0 container. You can use Hibernate Core and Hibernate Annotations in any Java EE 5.0 or Java SE 5.0 environment.

Read More

The decision to bump up the version number from 2.4 to 2.5 was based on the significant changes in the specification. In this release, there are four clarifications, two alterations to other documents, and the addition of six new major changes in the specification.

Many of the most significant changes make use of the new language features found in the JDK 1.5. As a result of the decision to use annotations, that version of Java has now been specified as the minimum required runtime environment. In the list of clarifications we have:

• calls to getReader() that have not been preceeded with a call to setCharacterEncoding() will acts as a no-op
• calling setHeader() with the arguments “Content-Length” and “0″ will close the reader to further alterations. All subsequent calls to setHeader calls will be ignored
• calls to HttpServletRequest.isRequestedSessionIdValid() will now return false if the client did not specify a session ID

The new features that can be found in this specifications include:

• Clarification on Session scope for when pages contain more then one session context
• the ability to apply a single filter to many requests and many filters to a single request
• the ability to create multiple mappings to the same Servlet
• Allow the use of alternative HTTP methods with authorization constraints
• Support the use of annotations to inject resources into a servlet
• Removal of the restriction on not being able to call setStatus() in error handling

Read more

Download Servlet 2.5 Spec