If your Glassfish v2.1 won't start...

If your Glassfish v2.1 won't start and the problem persists, there is probably a problem with your embedded JMS broker. I found in my logfiles the following hint:

[#|2010-01-14T10:27:36.227+0100|SEVERE|sun-appserver9.1|javax.enterprise.resource.resourceadapter|_ThreadID=10;_ThreadName=main;_RequestID=e2ff9fe6-ceb2-4436-bc22-5b88ed5dd49b;|RAR6035 : Resource adapter start failed : {0} javax.resource.spi.ResourceAdapterInternalException: MQJMSRA_RA4001: start:Aborting:Exception starting EMBEDDED broker=EMBEDDED Broker start failure:code = 1 at com.sun.messaging.jms.ra.ResourceAdapter.start(ResourceAdapter.java:476) at com.sun.enterprise.connectors.ActiveInboundResourceAdapter$1.run(ActiveInboundResourceAdapter.java:135) at java.security.AccessController.doPrivileged(Native Method) at com.sun.enterprise.connectors.ActiveInboundResourceAdapter.(ActiveInboundResourceAdapter.java:131) at com.sun.enterprise.connectors.system.ActiveJmsResourceAdapter.(ActiveJmsResourceAdapter.java:247) at com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:107) at com.sun.enterprise.connectors.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:300) at com.sun.enterprise.connectors.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:445) at com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:224) at com.sun.enterprise.jms.JmsProviderLifecycle.onStartup(JmsProviderLifecycle.java:428) at com.sun.enterprise.server.ApplicationServer.onStartup(ApplicationServer.java:442) at com.sun.enterprise.server.ondemand.OnDemandServer.onStartup(OnDemandServer.java:120) at com.sun.enterprise.server.PEMain.run(PEMain.java:411) at com.sun.enterprise.server.PEMain.main(PEMain.java:338) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.enterprise.server.PELaunch.main(PELaunch.java:412) Caused by: java.lang.RuntimeException: EMBEDDED Broker start failure:code = 1 at com.sun.messaging.jms.ra.EmbeddedBrokerRunner.start(EmbeddedBrokerRunner.java:268) at com.sun.messaging.jms.ra.ResourceAdapter.start(ResourceAdapter.java:472) ... 18 more |#]

The solution is simple: removal of the glassfish-v2/domains/domain1/imq/instances/imqbroker/lock file and restart the server. The cause of the problem is frequent change of the ipadress and booting glassfish without network on linux.

What You Can Build In 50 Minutes With Java EE 5/6?

My session was actually 50 and not 60 Minutes long - so I had to cut the REST and JMS stuff. However, I managed to develop the following:

Introduction of Java EE 5 (with Glassfish 2.1 and Netbeans 6.5):

  1. Started Glassfish v2.1
  2. Developed: 2 EJBs 3
  3. Exposed one as WebService
  4. Used DI to connect them
  5. Implemented a JPA entity
  6. Injected the EntityManager into a SessionBean
  7. Build an interceptor and applied it.
  8. Answered about 10 questions about different topics :-)
  9. Deployed a JSF
  10. Used databinding to create JPA
  11. Passed the JPA-Entity to the session bean
  12. ...I presented 3 slides :-)

Introduction to Java EE 6 (Glassfish v3 EA and Netbeans 6.7m2):

  1. Implemented and deployed a @Singleton, @Startup Bean
  2. Injected a no-interface @Stateless Session Bean into it
  3. Created a Servlet
  4. Injected the @Stateless Session into the Servlet
  5. Answered several questions again. 
The whole session was recorded and is available online.

15 Tips on JPA Rich Domain Modelling - Thinking In Objects - Not Mappings [For Greenfields]

  1. Forget about JPA, JDBC & CO for a moment.
  2. Try to identify concepts and abstractions from the target domain. Use them as candidates for entities.
  3. Reuse directly the names. Do not obfuscate them with additional technical naming conventions like XYZEntity or "BOs".
  4. Forget the database mapping and concentrate on good, DRY OO-design and fluent naming.
  5. Build objects, not structs - put logic into the entities if necessary.
  6. Forget getters / setters. Think about builders.
  7. Write unit tests for the business logic and run them, without involving the EntityManager etc. [optional - only if your logic in the entities becomes complex]
  8. Let the tool (JPA-provider) generate the DDL and the database layout.
  9. Write unit tests, without mocking out the database, early.
  10. Provide a lean facade/service layer (the easiest possibility are EJB 3 right now). It should only contain crosscutting concerns.
  11. Run load and stress tests.
  12. Import the database into an ER-Tool - optimize the DDL.
  13. Align the JPA-annotation, if needed.
  14. Provide orm.xml if required (you should have good reasons for it).
  15. Go to 11.
[Rich and anemic domain objects are discussed in-depth in the "Real World Java EE Patterns" book. See e.g. page 83 and 259]

EJB 3 - From Legacy To Secret Weapon

Why EJB 3.X rocks? I summarized my view in this JavaWorld article: "EJB 3: From legacy technology to secret weapon". It provides especially answers for questions, which are frequently asked, especially before, my Java EE projects and in trainings. It covers the basics stuff - a condensed excerpt from the first chapter of a book I'm working on.

Generic EJB 3 CRUD, DTOs and Lost Updates with Optimistic Locks and JPA

I got some feedback with concerns about a generic CRUD interface which I described in this post, as well as checked in into p4j5. The basic idea was the direct exposure of persistent JPA-entities to a remote client - without the use of DTOs. This approach works really well for simple use cases like e.g. master data management. However it isn't a silver bullet for more complex use cases. In general, the @Version in an JPA-entity is going to change in case the persistent state (the attributes) is changed. However the relations do not belong to this set. So, even in case you are using JPA with optimistic concurrency, changes to relations do not cause the @Version attribute to be increased / changed. In case the client changes a relation (e.g. deletes a link between the master 1----n> client), the @Version of the master entity will not be increased - concurrent access could cause lost updates in this case.

Beyond this "logical" problem - before you would like to start using detached entities over network boundaries, you should think about the following challenges:

  • Lazy loading - you have to preload the object graph, which is needed at the client. You could use e.g. "FETCH JOINS" for this purpose, or just invoking the methods
  • Lazy loading and AOP - some providers weave proprietary extension into the persistent entities. In this case it could be necessary to deploy additional libraries to the client as well.
  • The client will need at least the JPA-annotations in the classpath
  • In case you are sending a subset of the object graph to the client - automatic merge will be not always possible (what happens, in case the client deletes some childs?)
However - you can get rid off the most problems (except the "relations-versioning") running the persistence (business) layer in the same JVM as the presentation e.g. in a JSF enviroment it is perfectly possible.
I will discuss this issue in more detail during the upcoming talk at JUG HH (19.05.2008) as well.

Running Netbeans 6.1 on jdk 1.6.0_u10 beta (Consumer "JDK")

I just had some trouble with JAXB and had to upgrade the JDK (JAXB 2.1 comes with > JDK 1.6u4). I went a little bit further and installed the JDK 1.6.0_u10 beta, also known as the "consumer JRE / JDK". I just launched Netbeans 6.1 on it and: 

  1. Netbeans 6.1 launches in 5 seconds (with several Java EE 5 projects). It feels faster, than on jdk 1.6u4
  2.  It seems like the font rendering was improved  - it looks clearer.
  3. ...and JAXB 2.1 just works :-).
I will work with JDK 1.6.0u10 this week - let see how stable it really is.

Superb compilation of JVM parameters - from 1.3.1 to 1.6

From JDK 1.3.1 to 1.6. All major (about one hundred) JVM settings with explanation can be found here. Thanks to Michael Bien for the hint.

The Mystery of the Maximal -Xmx Settings, Ergonomics and Tuning

From time to time, especially developers working with windows, run into problems with JVMs maximum heap. Although in theory the maximum heap on 32bit OS should be 4 GB, it is actually on windows less than a half of the theoretical setting. The actual number is around 1.4GB, it is hard to reach 1.5GB. I found several resources, which point to the causes of this behavior. This older entry, explains the reasons (windows systems reserve some memory for "private use", which is no more available for applications). It contains some links to MSDN as well. This bug report, explains the behavior, as a problem in the JDK's dll. It mentions also, that other JVMs (like JRockit) are able to handle slightly more maximum heap. However on my Vista 32bit machine (3GB RAM), the highest heap I was able to set up was 1626m (it isn't able to start with 1628m...sometimes with 1629m it varies,) with Sun's JVM. I tested it with the SwingSet, the Swing demo application: java -Xmx1620m -jar SwingSet2.jar

If you are interested in GC/JVM tuning, this whitepaper is a good resource. It explains the default settings, tuning ideas and ergonomics in great detail.

JSF Matrix - most popular JSF/AJAX frameworks condensed

This matrix is really useful. It compares many (18) different JSF frameworks. Most of them come with a link to demos, documentation and license information. [Thanks to aquarium for this hint]

Hacking Java EE 5 is good for the environment!

GreenFire.dev.java.net is an opensource project which goal is to manage heating systems in convenient and efficient way. It is acually a bunch of ejb-jars (created with Netbeans 5.5, 5.5.1, and 6.0)  which are
deployed as an EAR to Glassfish v2. GreenFire abstracts early from the proprietary vendor extensions - the whole management is heating system independent. GreenFire consists of the following building blocks:

GreenFire's conceptual architecture 

Diagram created with Netbeans UML plugin.

GreenFire wakes up every 5 minutes (the archiver, actually the heartbeat - implemented by a timer bean) completes the following tasks:

  • It gathers the data (heating + configuration, weather forecast) and passes it to the „brain“
  • The brain is asked what to do (heating on/off, etc.)
  • The decision is passed to the integration layer and executed
  • All the data is stored in the Derby DB and can be used in reports.

The „brain“ dowloads a script from an URL (Glassfish as well). It has access to all the data (JPA entities) and can decide what to do.
The data in the JavaDB is used for reports and monitoring independently (it stores every 5 minutes all the data since about 2 years – and performs still very well -> no problems).
The Reporting-UI is accessing JavaDB to read the decisions and interesting data like external temperature, weather etc. – not directly the heating system (decoupling – the serial port seems not to be thread safe).
However the current data is broadcasted every five minutes using JMS internally (inside the application server) the shoal.dev.java.net / fishfarm.dev.java.net framework as well and can be accessed with every device (currently multi-media system, PCs, working on Java ME) over W-LAN. Even the following widget is updated by the JMS/Shoal heartbeat:

The rules for the heating should be changed without redeploying and especially recompiling the application.
For the implementation the Fluid Kernel, Persistent Anemic Objects, Lookup Utility etc.. pattern were used (see: http://p4j5.dev.java.net).

At the creation time Groovy was chosen (JDK 1.5 time, no JSR-223) for the implementation of the rules. In the next release JavaScript is going to be used (is already shipped with Java 6, faster and totally sufficient for greenfire‘s purposes). GreenFire is running since 2 years in my house - the energy saving is considerable (over 30%).

Online Workshops
...the last 150 posts
...the last 10 comments