IDE: 5 most favorite NetBeans features

Development with pleasure....
NetBeans has many interesting features that make development very easy, with few steps, and makes for a very productive environment, in terms of getting your product to market very quickly.

It is very hard to limit my talking to only five features, while this IDE has tons of interesting features. But here I am going to mention my most favorite 5 features I am daily using in my development process on many platforms:

1. It is the reference development implementation IDE:
   

   I am a JCP (Java Community Process), EC (Executive Committee), a JSRs (Java Specifications Request) adopter and FishCAT (Glassfish Community Acceptance Testing) contributor especially in Java, SE & EE world. While I am in early phases of testing the specifications, I need an IDE which support those technologies and made it easy to test and develop them, to report bugs, enhancements and confirms that JSRs Specs are valid against RIs, and with other JSRs on latest RI Application server like Glassfish.
   

   NetBeans offered all of this for us to streamline the process, with almost a nightly and weekly builds alongside JSRs RIs builds, which we use to test previously mentioned RIs betas.

   The most interesting part of the story here is when we released Java EE 7 on last Mid of June 2013; there was already NetBeans 7.4 was generally available released to fully support development of Java EE 7 technologies. And this happens also for JDK 8 when it released 18-March 2014, there was NetBeans 8.0 fully support Java SE 8.0.

2. Android Mobile development made easy:
   

   NetBeans shipped with a very great support for mobile development either it was pure Android development in term of this is a Java Based IDE or Hybrid development in term of frontend technology support (HTML5, CSS3 and JavaScript).

   With a very productive plugin NBAndroid you can develop a pure Android project compatible with original ADT SDK (Android Development Toolkit) project structure, test, emulate and deploy on emulators as well as native devices at the same time. You should give it a try if you interested in mobile development.

   Create a new Project:
   
   
   
   
   
   Identify Properties:
   
   
   
   
   
   Created project:
   
   
   
   
   
   Runs On Android Emulator:
   
   
   
   
   
3. Hybrid Mobile development support:
   

   Hybrid mobile development is never made easy as now in NetBeans nowadays, NetBeans introduced a hybrid mobile development based on Cordova open source mobile framework. Which is one of the most popular frameworks to develop hybrid mobile applications.

   While NetBeans gives a great and solid support for frontend engineering technologies like JavaScript, HTML5, CSS3, Frameworks like AngularJS, NodeJS, and jQuery core, mobile, and UI … etc.

   Which made it easy to develop a Hybrid based mobile applications for both Android and iOS in one shoot with few clicks. Without context-switching to other IDEs to accomplish the task.

   It has complete support for Apple iOS development toolkit and Android ADT SDK, therefore you can test your application locally for mobile web and on emulators/devices of both mobile OSs, then export final product either it was .apk binary for android or .ipa for iOS, for final deployment on Apple store or Google play store.

   Creating the project:
   
   
   
   
   
   Choosing template:
   
   
   
   
   
   Identifying project properties:
   
   
   
   
   
   Choosing deployment method:
   
   
   
   
   
   Deployed on iOS simulator:
   
   
   
   
   
4. JavaScript libraries in one place:
   

   If you are a frontend engineer, then you got the right choice, yes this IDE is for you, I know you need to develop a modern web application, but wait this needs many JavaScript modules and libraries to do it.

   One among the very panic tasks in web development nowadays, is to search for JavaScript tools and setup your project for them, then download each JavaScript libs from different sites with there resources and support libs, in addition you have also to manage their updates to fix problems or get a new feature.

   NetBeans comes with a build in tool that allows you to get your JavaScript libraries in one shoot from the IDE directly and mange their updates from the same place.

   You will find almost all JavaScript libs you need, and you can filter your choice from the tool to pic up the right libs you need for your project, and where to put them in your project.

   As mentioned in first picture the libs were updated on Apr 26, 2014, just click and will updates all libs to today releases.

   It saves me a bunch of site visiting and worrying about updating them, and even adding new ones in future of the project.

   The JavaScript tool:
   
   
   
   
   
   Pickup and filter your choices:
   
   
   
   
   
5. SOAP based client/Web Services in one click:
   

   I am working in government environment, which requires much integration between systems either directly or through a G2G (Government-to-Government) hub, each one needs a specific integration requirements.

   If it is directly, you have to define you web service annotations on interface based on your backend EJB session bean interface or separate endpoint interface to decouple your Endpoint from your façade, then generate WSDL to be consumed by others.

   Other scenarios is to go to a Top-Down approach, in developing WSDL first to be certified on G2G hub based on their standards, then generate service endpoint interface from them.

   Lately I have been asked to develop a Pension G2G WSDL definition and at the same time generate endpoint service interface to begun the testing in one week.

   I have accomplished this task in 3 days using NetBeans, it has a tremendous support for XML, XSD development, and after finishing the WSDL definition, I need to confirm a correct endpoint service creation, Before publishing service WSDLs to G2G authors.

   Okay from NetBeans I have created a Web Service from WSDL, passed the WSDL and click finish, that’s all.

   The surprise was it generates the service endpoint correctly as WSDL def. and at the same time created Service ports and client to test service in one shoot.

   All I have to do is to implements my service endpoint operations and huryaaaa finished my task.

   Adding WSDL and Identifies project attributes:
   
   
   
   
   
   Generated Service endpoint:
   
   
   
   
   

Thanks for NetBeans team for such support and made it a development with pleasure.

JPA2: Forcing JPA "Query" to get fresh data Rather Than Cached data.

Problem

The default behavior of EntityManager is using cached results from a database query, and you want to force a query to be executed each time a table is loaded, rather than allowing the results of the cache to be displayed.

Especially when you are working with database stored procedures, which changes the data on database server, but when you query this data, cached one is displayed, instead of new changed data.

There was a solutions by

1. Disabling the cache from persistence.xml or
   
   
2. Calling EntityManagerFactory.getCache().evictAll(); method in an Interceptor, I was using this solution.

Nevertheless, these solutions works but with problem, which is the performance and bandwidth is hurt, because you load all fresh and read only data such as lookups and configuration data, from database to application.

But I need to get a fresh data instead of cached ones but for specific query, so let's dive into the solution.

Solution
After the javax.persistence.Query instance is created, set a hint, javax.persistence.cache.retrieveMode, to bypass the cache and force the query to be executed. In the following lines of code, the Book entity is queried, and the cache is bypassed by setting the hint:

Upon execution, the query will be forced to execute, returning the most current results from the underlying database table.

Working mechanism
There are often occasions when an application requires the most current table data to be displayed or used for performing a given task. For instance, if you were to write a Stock Exchange application, it would not make sense to cache the current stock results since old data would not be very useful to investors.

In such cases, it is imperative to force queries to be executed and bypass any caching. This is possible via the use of hints that can be registered with javax.persistence.Query instances.

By setting the javax.persistence.cache.retrieveMode hint to CacheRetrieveMode.BYPASS, the JPA is told to always force the execution of a query. When the query is executed, it will always return the most current results from the database.

References:
More on cache disabling mechanisms could be fund on Java EE 6 Tutorial Specifying the Cache Mode Settings to Improve Performance

Glassfish: Dynamic Reloading Feature

Dynamic Reloading

If dynamic reloading is enabled, you do not have to redeploy an application or module when you change its code or deployment descriptors. All you have to do is copy the changed pages or class files into the deployment directory for the application or module. The deployment directory for a web module named context-root is domain-dir/applications/context-root.

The server checks for changes periodically and redeploys the application, automatically and dynamically, with the changes.

This capability is useful in a development environment because it allows code changes to be tested quickly.

Dynamic reloading IS NOT RECOMMENDED for a production environment, however, because it may degrade performance. In addition, whenever a reload is done, the sessions at that time become invalid, and the client must restart the session.

Note: In the GlassFish Server, dynamic reloading is enabled by default.

To Disable or ModifyDynamic Reloading

If for some reason you do not want the default dynamic reloading behavior, follow these steps in the Administration Console.

1. Open the URL http://localhost:4848/ in a browser.
   
   
2. Select the GlassFish Server node.
   
   
3. Select the Advanced tab.
   
   
4. To disable dynamic reloading, deselect the Reload Enabled check box.
   
   
5. To change the interval at which applications and modules are checked for code changes and dynamically reloaded, type a number of seconds in the Reload Poll Interval field.
   
   The default value is 2 seconds.
   
   
6. Click the Save button.

JEE: Java Naming and Directory Interface API (JNDI)

The Java Naming and Directory Interface (JNDI) API provides naming and directory functionality, enabling applications to access multiple naming and directory services, including existing naming and directory services, such as LDAP, NDS,DNS, and NIS.

The JNDI API provides applications with methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes.

Using JNDI, a Java EE application can store and retrieve any type of named Java object, allowing Java EE applications to coexist with many legacy applications and systems.

Java EE naming services provide application clients, enterprise beans, and web components with access to a JNDI naming environment. A naming environment allows a component to be customized without the need to access or change the component’s source code. A container implements the component’s environment and provides it to the component as a JNDI naming context.

A Java EE component can locate its environment naming context by using JNDI interfaces. A component can create a javax.naming.InitialContext object and look up the environment naming context in InitialContext under the name java:comp/env.

A component’s naming environment is stored directly in the environment naming context or in any of its direct or indirect subcontexts.

A Java EE component can access named system-provided and user-defined objects. The names of system-provided objects, such as JTA UserTransaction objects, are stored in the environment naming context java:comp/env. The Java EE platform allows a component to name user-defined objects, such as enterprise beans, environment entries, JDBC DataSource objects, and message connections. An object should be named within a subcontext of the naming environment according to the type of the object.

For example, enterprise beans are named within the subcontext java:comp/env/ejb, and JDBC DataSource references are named within the subcontext java:comp/env/jdbc.

JEE6: Who Needs Aspect-Oriented Programming?

In Java EE, there is rarely an obvious use case for AOP.

According to Wikipedia, aspectoriented programming aims to separate reusable functionality from the business logic:

“In computing, aspectoriented programming (AOP) is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns. AOP forms a basis for aspect-oriented software development.”

AOP was a hot topic a few years ago, but it never really took off in J2EE—and for good reason.

Aspects Are Commodities The integral parts of the Enterprise JavaBeans (EJB) 1.0 specification (JSR 318) in early 1998 were aspects. The developer had to develop the Bean class and the Remote and Home interfaces but none of the cross-cutting aspects. Threading, pooling, security, transactions, session handling, and even persistence were configurable aspects cleanly separated from the business logic.

The cross-cutting functionality was configurable in the early EJB 1.0 days with POJOs.

With the advent of EJB 1.1 and J2EE, Java classes were replaced with XML, and the recent Java EE 5 and Java EE 6 specifications made XML optional. You can configure the vast majority of all use cases with annotations and override them with XML.

Although the whole EJB 1.0 idea was based on aspects, you will find only two mentions of the word aspect in the original specification in different contexts.

AOP and EJB 1.0 were “invented” nearly at the same time.

In J2EE, the configurable decoration of an EJB bean with, for example, transactions was just an integral part of the development experience. Other frameworks
provided the same functionality but called that functionality AOP.

You will have a number of aspects by defining a simple EJB 3.1 bean. For example, a stateless EJB 3.1 bean comes with transaction and lifecycle aspects out of the box.

The method greet() is never invoked directly. The container dispatches the invocations to free EJB instances from the pool. Also, transactions are started before each method invocation.

The method call is processed by a chain of default and configurable aspects until it reaches the actual business logic. Outside the application server, you would probably implement the same functionality with the decorator pattern or with a more generic solution, such as AOP.

* For complete article by Adam Bien in Java Magazine check it out here

JPA: 2 ways to get container-managed EntityManager in servlet

In Thread-safety when injecting EntityManager post, I wrote about the danger of using field/setter injection to get EntityManager in servlets and compares container-managed EntityManager vs application-managed EntityManager.

What if I need a container-managed EntityManager in my servlet class?
There are 2 ways to do that:

1. type-level injection + JNDI lookup

2. web.xml + JNDI lookup

The persistence-context-ref is declared in web.xml:

JPA: Thread-safety when injecting EntityManager

As I wrote in post Why we need type-level injections in JavaEE, injecting EJB 3 stateful beans into servlet instance fields is not thread-safe. Along the same line, injecting EntityManager with @PersistenceContext into servlet instance variables is not thread-safe, either. EntityManager is just not designed to be thread-safe.

For example, the following code snippet of a servlet class is incorrect:


One way to fix this is to inject EntityManagerFactory instead. EntityManagerFactory is guaranteed to be thread-safe. For example:

Continuing container-managed EntityManager vs application-managed EntityManager.

There are important differences between the injected EntityManager, and the EntityManager created from an injected EntityManagerFactory. Basically, injected EntityManager is container-managed, meaning all of its lifecycle is controlled by the container (web container or EJB container). Application code cannot close it, or otherwise interfere with its life.

In addition, for a container-managed EntityManager, its associated PersistenceContext is automatically propagated along with the underlying JTA, from servlet A to servlet B, from servlet to EJB, from EJB a to EJB B, and so on. As such, EntityManager of the same configuration injected into various classes can share the same PersistenceContext in a call stack.

On the other hand, EntityManager created from EntityManagerFactory is application-managed EntityManager. Application code is responsible for managing its whole lifecycle. And there is no PersistenceContext propagation for application-managed EntityManager.

Are all EntityManager's obtained from EntityManagerFactory application-managed EntityManager? Yes.

Is it possible to get a container-managed EntityManager from EntityManagerFactory? No.

You may have read about the method EntityManagerFactory.getEntityManager(), which returns a container-managed EntityManager. This method was considered and included in the early draft version of Java Persistence API, but was eventually removed from its final release.

JPA: Why we need to specifies the type-level injections in JavaEE?

As I wrote in the Injection level-types in JavaEE5+, JavaEE type-level injection is more verbose than field and setter injections. So why don't we just all use the simple field or setter injections? Well, there are sometimes a type-level injection is more appropriate

1. You want to lazily initialize a field such as a data source or bean. Having the container to initialize a field via field injection or setter injection has its overhead. With type-level injection, you have the resource and EJB reference fully configured without descriptors, but defer the actual initialization. Whenever you need the resource, just look it up.

Type-level injection also works well if you want to reference the injected resource in some non-component utility classes that are in the same naming context. Since only JavaEE component classes can take injections, you can't inject into POJO utility classes. For example, you can



The above example will also if we instead use field or setter injection. But the instance filed in FooServlet class that takes the injection may not be used at all. Another approach is to pass the data source reference injected into FooServlet as method parameters to ServletHelper. But it pollutes the API. It appears more natural, at least to me, to use type-level injection in this case.

2. You want to restrict the scope or sharing of the variable that references the resource. Field and setter injections both use instance variables, which are accessible to all methods and all threads of the current component instance. Instance variables represent shared states. With type-level injections, you typically assign the resource to a local variable and thus is thread-safe.

This is the reason why you shouldn't inject an EJB 3 stateful session bean into a servlet class variable. In so doing, this stateful bean variable will be shared by all request-processing threads running inside the servlet's service method. Servlet is stateless, so it should not keep state (the stateful session bean reference).

JPA: Injection level-types in JavaEE5+

There are 3 types of resource injections in JavaEE in the order of usage frequency:

1. Field injection.
2. Setter injection.
3. Type-level injection. 

Unlike field and setter injections, type-level injections are not really injection. It does not inject anything into anywhere; it just declares a resource reference in a descriptor-free manner.

To use resource injected at type-level, you will need to do a traditional JNDI lookup. What we have saved here, compared to pre-JavaEE-5, is there is no need for deployment descriptors.

A servlet example in glassfish:


Type-level injections are inherently verbose, compared to field and setter injections, where a bare @EJB or @Resource is sufficient in some cases. Field and setter injections can use the field type and parameter type to infer the resource type, respectively.

Type-level injections can't. All the necessary attributes must be present.

• For @Resource, you must specify at least name and type. 
• For @EJB, you must have at least beanInterface and name.

Glassfish 3.1.2: Unable to load resource [com.mysql.jdbc.EscapeProcessor]

While I am building JEE6 web profile application, using EJB3.1, JPA2.1, JSF (IceFaces 3) against MySQL database v5.1.15, my java web app fails in Netbeans v7.1 when I try to run it.

Netbeans reports successful deployment, but then I get this error when executing a JPA query against MySQL:

java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource [com.mysql.jdbc.EscapeProcessor], because it has not yet been started, or was already stopped.

This error occurs at the first query against the database. The entire application works fine with Netbeans version 7.1.
One potential clue is that I had to manually add the MySQL driver to the project for unit test the project using embedded glassfish 3.1.2.

After reviewing/tracing the problem and some googling about the problem here is the fix:

1. For unit testing put the MySQL driver in the test libraries only don't add it to the project to final deployment.
2. For production, the MySQL driver should not be in the project ... it should be in <DOMAIN>/lib/ext... in your glassfish v3.1.2 folder.

If there is any help just leave your comment.

App. Server: GlassFish 3.1.2 Released

Oracle GlassFish Server 3.1.2 has just been released and is ready to download.

Oracle GlassFish Server 3.1.2 improves upon its ease-of use features, flexibility and improved developer productivity with several enhancements. Do you want an application server that's both state-of-the-art and production-ready? Johan Vos, CTO at LodgON, says GlassFish is his favorite application server because: 

"GlassFish contains the most advanced, state-of-the art technology that is seen in similar products a few years later and the quality of GlassFish is very high, the software is ready to be used in production."

Here are the highlights of the Oracle GlassFish Server 3.1.2 release:

• Improved console startup time over previous versions of Oracle GlassFish Server.
• Enhanced configuration of Java Message Service (JMS) clusters for fault tolerance and failover capabilities.
• Easier Load Balancer configuration for faster throughput and reduced latenc.
• Enhanced security with SSL Encrypted traffic between the Domain Administration Server and remote instances.

• Support for the WebSocket Protocol RFC 6445, enabling bi-directional communication between a client and server, adding a web-origin based security model for browsers
.
• New DCOM support. Windows users now have the flexibility to administer Glassfish clusters and instances remotely using SSH or DCOM.

• New Support for non-Multicast clustering. GlassFish High-Availability clustering is now possible in environments where multicast is disabled.

• Improved EclipseLink integration to enable data binding with JAX-WS. EclipseLink integration provides TopLink Grid support for using Coherence as a 2nd level data cache.

Learn the differences between Oracle GlassFish Server and GlassFish Server Open Source Edition at glassfish.java.net.

You can download GlassFish 3.1.2 from the Oracle Technology Network.

JEE7: Looking ahead to a new era

Get educated about Java EE 7 JSRs.

With the release of Java EE 7 scheduled for the second half of 2012, projected JSRs are all up and running. The Java EE 7 release, which will reflect the evolving needs of the industry as it moves into the cloud, is date driven: anything not ready will be deferred to Java EE 8.

Here is an update and summary of the key features of different specifications in the Java EE 7 platform.

JEE6: Stress Testing Java EE 6 Applications, how to?

Use stress testing to identify application server configuration problems, potential bottlenecks, synchronization bugs, and memory leaks in Java EE 6 code.

Unit and integration tests are helpful for the identification of business logic bugs, but in the context of Java Platform, Enterprise Edition 6 (Java EE 6), they are meaningless. Both integration and unit tests access your application in a single-threaded way.

After the deployment, however, your code will always be executed concurrently.

Stop Talking, Start Stressing

It is impossible to predict all nontrivial bottlenecks, deadlocks, and potential memory leaks by having theoretical discussions. It is also impossible to find memory leaks with unit and integration tests. Bottlenecks are caused by locks and I/O problems that are hard to identify in a single-threaded scenario. With lots of luck and patience, memory leaks can be identified with an integration test, but they can be far more easily spotted under massive load.

The heavier the load, the greater is the probability of spotting potential concurrency and robustness problems. Cache behavior, the frequency of Java Persistence API (JPA) OptimisticLockException, and the amount of memory needed in production can also be evaluated easily with stress tests.

JEE6: Interfaces on Demand with EE6 (CDI & ejb3.1)

Interfaces are no longer required with Java EE 6, so you can use them more consciously for the realization of business logic.

Introduction

Since Java Platform, Enterprise Edition 6 (Java EE 6), interfaces are no longer required by the container in order to realize common use cases. Transactions, security, custom aspects, concurrency, and monitoring are also available for plain classes without any interfaces. Java EE 6 made interfaces meaningful again. Since they are no longer required by the platform, you can use them more consciously for the realization of business logic. An interface becomes a vehicle for encapsulation or abstraction, as it was originally intended to be:

“Interfaces are used to encode similarities which the classes of various types share, but do not necessarily constitute a class relationship. For instance, a human and a parrot can both whistle; however, it would not make sense to represent Humans and Parrots as subclasses of a Whistler class. Rather they would most likely be subclasses of an Animal class (likely with intermediate classes), but both would implement the Whistler interface.” [http://en.wikipedia.org/wiki/Java_interface]

Unfortunately, interfaces are not used within the context of Java EE as a tool for encoding similarities; they serve as reassurance for possible, but unlikely, future enhancements. Extensive use of interfaces derives from a belief that they might be helpful in the future.

JEE6: Part 3- The Java EE 6 Platform introduction

Part 1 | Part 2 | Part 3

EJB Technology, Even Easier to Use

Enterprise JavaBeans technology is the server-side component architecture for developing and deploying business applications in Java EE. Applications that you write using EJB technology are scalable, transactional, and secure. EJB 3.0, which is part of the Java EE 5 platform, made the technology a lot easier to use.

The latest release of the technology, JSR 318: Enterprise JavaBeans 3.1, which is available in the Java EE 6 platform, further simplifies the technology and makes many improvements that reflect common usage patterns.

Some improvements made in EJB 3.1 are as follows:

•  No-interface view. Allows you to specify an enterprise bean using only a bean class without having to write a separate business interface.
• Singletons. Let's you easily share state between multiple instances of an enterprise bean component or between multiple enterprise bean components in an application.
•  Asynchronous session bean invocation. Enables you to invoke session bean methods asynchronously by specifying an annotation.
•  Simplified Packaging. Removes the restriction that enterprise bean classes must be packaged in an ejb-jar file. You can now place EJB classes directly in a WAR file.
• EJB Lite. Is a subset of EJB 3.1 for inclusion in a variety of Java EE profiles.

JEE6: Part 2- The Java EE 6 Platform introduction

Part 1 | Part 2 | Part 3

Enhanced Web Tier Capabilities

Some of the most significant enhancements made in Java EE 6 appear in the web tier. As mentioned earlier, one of the goals of Java EE 6 is to make the platform more extensible, and two key improvements in the area of extensibility are web fragments and shared framework pluggability. These two new features are provided in Java EE 6 by Servlet 3.0 technology. Servlet 3.0, JSR 315, the latest version of Servlet technology, offers some other valuable enhancements such as support for asynchronous processing and support for annotations.

Another important Java EE 6 web tier technology is JSF 2.0, the latest version of JSF technology. Among its benefits, JSF 2.0 simplifies page and component authoring through Facelets, and adds support for asynchronous JavaScript and XML (commonly referred to as Ajax), and annotations.

JEE6: Part 1- The Java EE 6 Platform introduction

Part 1 | Part 2 | Part 3

Java Platform, Enterprise Edition (Java EE) is the industry-standard platform for building enterprise-class applications coded in the Java programming language. Based on the solid foundation of Java Platform, Standard Edition (Java SE), Java EE adds libraries and system services that support the scalability, accessibility, security, integrity, and other requirements of enterprise-class applications.

Since its initial release in 1999, Java EE has matured into a functionally rich, high performance platform. Recent releases of the platform have also stressed simplicity and ease of use. In fact, with the current release of the platform, Java EE 5, development of Java enterprise applications has never been easier or faster.

Java EE 6 adds significant new technologies and extends the usability improvements made in previous Java EE releases.

Progress continues. The next release of the platform, Java EE 6, adds significant new technologies, some of which have been inspired by the vibrant Java EE community. It also further simplifies the platform, extending the usability improvements made in previous Java EE releases.

This article highlights some of the significant enhancements in Java EE 6; it consists of three parts Part 1, 2 and 3.

JEE6: Observer pattern/Event implementation

Java Enterprise edition jee6 Observer pattern/Event implementation using CDI (JSR-299/JSR-330) and EJB3.1

In few steps you will create the pattern as the following.

1. You will have to define an event class first. It can be any POJO you like:

public class HelloEvent {
    private String message;
    public HelloEvent(String message) {
        this.message = message;
    }
    public String getMessage() {
        return message;
    }
}

2. An event has to be fired by an injected javax.enterprise.event.Event class. It can be injected into an EJB 3.1:

@Named("messenger")
@Stateless
public class HelloMessenger {
    @Inject Event<HelloEvent> events;
    public void hello(){
        events.fire(new HelloEvent("from bean " + System.currentTimeMillis()));
    }
}

3. The event can be consumed by another Session Bean / managed bean. You only have to use the @Observes annotation:

@Stateless
public class HelloListener {
    public void listenToHello(@Observes HelloEvent helloEvent){
        System.out.println("HelloEvent: " + helloEvent);
    }
}

4. You can access the EJB 3.1 directly - without any backing beans. You only have to use the name (messenger) from the @Named annotation in the JSF 2.0 page and bind the action to the method (hello()) name:

    <h:body>
        <h:form>
            <h:commandButton value="Fire!" action="#{messenger.hello}"/>
        </h:form>
  <h:body>

The project (Jee6ObsorverEvents) was implemented in few minutes with NetBeans 7.1, tested with Glassfish v3.1.1

JEE6: Is war package is the new ear ?

The pragmatic way of modularization and packaging...

It is not only possible to put EJBs and JSR-299 Beans together directly into a WAR - EJBs can be also packaged separately into a JAR. After copying the “ejb-jar” into the [WAR]/WEB-INF/lib folder, the included beans become automatically available to the web app.

No additional configuration or tweaking is required. In the contrary to the the old EAR packaging, all the classes are loaded with the same classloader. There is no difference between packaging the beans in a standalone JAR, or putting the byte code directly into the WEB-INF/classes folder.

You could even sprinkle the beans in as many JARs as you like - the Dependency Injection between them will just work. Because all the JARs inside the WEB-INF/lib are loaded by exactly the same classloader - it just behaves like a single JAR.

The new Java EE 6 WAR-packaging is interesting for the majority of the “business” projects with “weak” requirements regarding the modularization. You can partition your software into dependent pieces, without paying the costs of true JAR-isolation.

The EAR packaging is still interesting for projects with higher modularization requirements - here the EJB-JARs will be loaded with an isolated classloader separately. In the majority of all cases it is just an overhead: it is unlikely, that someone will replace a single EJB-JAR without rebuilding and testing the whole EAR...

from Adam Bien's blog

IDE: NetBeans 7.1 released

The NetBeans community is proud to announce the release of NetBeans IDE 7.1.

This release introduces support for JavaFX 2.0 by enabling the full compile/debug/profile development cycle for JavaFX 2.0 applications. NetBeans IDE 7.1 also provides significant Swing GUI Builder enhancements, CSS3 support, and tools for visual debugging of Swing and JavaFX user interfaces. Additional highlights include Git support integrated into the IDE, new PHP debugging features, various JavaEE and Maven improvements, and more.

"The latest NetBeans IDE release provides the Java developer community with many new features to help them create leading-edge Web, mobile and enterprise applications,” said Ted Farrell, chief architect and senior vice president, Tools and Middleware, Oracle. “As the first IDE to support JavaFX 2.0, NetBeans IDE 7.1 not only gives developers rich support for developing JavaFX 2.0 applications, but also ensures they have access to all of the advances delivered in the latest Java platform releases.”

NetBeans IDE 7.1 is a free, open source IDE available for Windows, Mac, Solaris, and Linux that enables developers to rapidly create Web, enterprise, desktop, and mobile applications for the Java platform. 

For NetBeans 7.1 features you can watch the following screen cast NetBeans IDE 7.1 Overview.