#There are two types of session beans: stateful and stateless.

#Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients.

#A stateless session bean can implement a web service, but other types of enterprise beans cannot.

#A session bean represents a single client inside the Application Server.

# Like an interactive session, a session bean is not persistent. (That is, its data is not saved to a
database.) When the client terminates, its session bean appears to terminate and is no longer
associated with the client.

#The state of an object consists of the values of its instance variables.(stateful session bean).

# A stateless session bean does not maintain a conversational state with the client. When a client
invokes the methods of a stateless bean, the bean’s instance variables may contain a state specific to that client, but only for the duration of the invocation.

#A message-driven bean is an enterprise bean that allows Java EE applications to process messages asynchronously.

#A message-driven bean’s instances retain no data or conversational state for a specific client.

#Message-driven beans have the following characteristics:
They execute upon receipt of a single client message.
They are invoked asynchronously.
They are relatively short-lived.
They are stateless.

#Session beans allow you to send JMS messages and to receive them synchronously, but not asynchronously.To receive messages asynchronously, use a message-driven bean.

#When you design a Java EE application, one of the first decisions you make is the type of client access allowed by the enterprise beans: remote, local, or web service.

#If you aren’t sure which type of access an enterprise bean should have, choose remote access. This decision gives you more flexibility.

#The Webserver: Just Receive the request from the client and forward to Webcontainer and do the Response vice versa.
Web Container: Creates HTTP Request and Response for the Servlet calls the appropriate servlet service
method (doGet or doPost) to service the client request.



So, one more Java event happened this last weekend down here in Brazil. The Developers Conference, organized by Globalcode, took place on the 6th and 7th of November in São Paulo, and it is going also to Florianópolis (9th) and Rio de Janeiro (11th).

Like last year, the event featured international speakers, and was really nice. In this and two other posts, I’ll be talking about what happened in São Paulo, since this is the location I attended.

Lets start off saying that this edition was the best one until now. Among the international speakers, we had Rod Johnson (Springsource), Ed Burns (Sun) and Mike Keith (Oracle).

Opening

The event started with Vinicius Senger’s (Globalcode) dancing robots. They started some music and turned the robots on, which started to dance. The dance was programmed by themselves into the toys. Really funny =)

dancing robots

Fast forward to a break that happened later, here is a closer picture of the robots in the stage above:

robots!

For the music, they used a parody they made themselves. They created a new music, based on an existing one, with lyrics related to software development. As soon as I have the link, I’ll post it here. That was really really funny.=D

One thing that always grab my attention at those events are how much some people are excited about their stuff. You could see this clearly about Vinicius in the entire event; but special was his scream at the end of the opening: “I love what I do!”

Rod Johnson

Rod Johnson was the first international speaker. He talked about how things are evolving in the software development world, and mentioned things like the fact that different kinds of data storage might be interesting, instead of using relational databases for everything; cloud computing and how Springsource (and VMware) might be involved (CloudFoundry). It also seemed that he likes Groovy and Grails a lot.

rod johnson at tdc day 1

The talk was a little bit philosophic but interesting nonetheless.

Career Panel

Next we had a career panel, featuring the three international speakers. They basically told us some stories about how they started their careers, and things like what would they expect in interviews and the like.

career panel

Lightning Talks

Spread during the day, we also had lightning talks, with subjects like GWT, Google Guice, Agile Developement and Software Architecture, EJB 3.1 (samples, available on Kenai) and ScrumToys (which is available as a NetBeans sample project and a Glassfish sample application). Two pictures of those:

agile and architecture

ejb 3.1 samples

And in-between presentations, Vinicius appeared again with one more toy. Now, a robotic balloon:

robotic balloon

Mike Keith

Following we had Mike Keith talking about J2EE 6. He talked a little bit about the timeline of the past releases, and about a few new features coming. Note-worthy, although not that new, is the definition of JEE Profiles – different versions of the application server, with different sets of libraries, for different scenarios.

For some odd reason, I don’t have a picture of this… so lets move on.

Ed Burns

Finally, Ed Burns talked about JSF 2.0 components. Some quick highlights: development of components should now be really easy; components can be built in groovy and can be packaged together with CSS and JS files; support for EL inside CSS files and CSS can be put anywhere in the page – JSF takes care of moving them to the page head tag later.

JSF 2.0 Components with Ed Burns

And that was all for day 1 of the event! The next post will be about the second day, which was as busy as the first one. Stay tuned!

EDIT: Click here for the coverage of the second day of the event.

EDIT 2: Here is the link for the video.

Since probably from Tuesday I will be busy studying Spring and other technologies, I’d like to dive in a bit and see what are the foundations of this platform. Probably this topic will gain deepness with time, but now let’s start really simple and watch one feature that makes Spring different from EJB: the Inversion of Control pattern.

Imagine to have two classes, Door and Handle. The Door has a private variable that is its Handle, and when it is instantiated with new Door(), it will build a new Handle() inside its constructor as seen in the following diagram.

If we set up things in this way, there is a tight coupling between Door and Handle, and probably every change to the Handle class (for example, adding a parameter to the constructor) will affect even the Door class: to prevent this high coupling (class Door is responsible even for the creation of the Handle), we could have a IoC framework, that will have the responsibility to inject the instance of class Handle to the class Door, confining changes of class Door to the IoC framework. Class Door will only have a private variable Handle and a method setHandle(Handle h) to get the reference from the IoC framework.

In this case, class Door and Handle are independent, since the IoC framework uses the public method of class Door to set up the Handle.However, there are three different ways to implement the IoC pattern, and every web framework uses its implementation.

Setter-based IoC: like in the example I showed before, we use a setter method to inject the referred object (Handle) in the referring object (Door). In this way, even if Handles change a lot during its lifetime in the development, we prevent Doors from changing: the main drawback is that we expose the internal variables with setter methods, violating the key OO principle of classes, that is encapsulation of data.

Constructor-based IoC: we use a constructor to set the reference of the object, so that only the creator knows about the referenced object.

Interface-based IoC: objects have to implement a specific interface of the IoC framework, so that the framework will be able to properly inject the objects. In this way there is no need for an external configuration file with the objects’ references. This locks your application to a specific IoC framework.

I am sure this approach has a lot of advantages, most of all when you don’t know much about the referred class and how it will change in the application lifecycle, but i think that in order to fully understand its potential it should be seen in a well defined context, comparing the same web application written with EJB and with Spring that accompanies the IoC pattern with principles of Aspect Oriented Programming. Hope to learn this in the future.

GUI – Graphical User Interface;

Client-Server – a distributed application architecture that divides tasks or workloads between service providers (servers) and service requesters (clients). Generally, it describes the relationship between two programs, where one makes a service request to another. In a network, multiple server programs can be run on one host, the server machine. Client programs initiate communication sessions with servers, which await (listen to) incoming requests. Opposing to Peer-to-Peer and Client-queue-Client architectures.

API - Application Programming Interface – an interface that a software program implements in order to allow other software to interact with it; much in the same way that a software might implement the GUI in order to allow humans to operate with it.

J2EE - Java Platform, Enterprise Edition;

JMS - Java Message Service API is a messaging standard that allows application components based on the A2EE to create, send, receive, and read messages. It enables distributed communication between components. Java applications that use JMS are called JMS clients; system that handles routing and delivery of messages - JMS Provider; JMS Application – a business system, composer of many JMS clients, and, generally, one JMS Provider.

EJB – Enterprise JavaBeans. A server side component architecture for Java Platform, Enterprise Edition. EJB technology enables rapid and simplified development of distributed, secure and portable applications based on Java technology.  In a typical application, EJBs contain the application’s business logic and business data, and is solving many issues which appear while using the standard Java objects.

DSRC requires Software Professionals (Walk-In Interviews)

Looking for dynamic Software Professionals for the following skills:

— Java – Technical Architect:
a). 7-10 years experience in J2EE Design and Architecture, UML, OOAD, Design Patterns, EJB, Struts, JSP, EJB, JDBC, JNDI, Web Services, Weblogic App Server
b). Struts Framework, Jakarta Tiles framework, Hibernate, Spring Framework, Eclipse 3.0, Solaris 9, Rational ClearCase, Rational ClearQuest, Oracle Database
c). Knowledge of SOA & SCA. Sun Certification Enterprise Architect would be preferred
— Mainframe-Developers / Sr. Developers : 3-8 years experience with extensive Real Time Project experience in COBOL, JCL, VSAM, CICS, DB2, IMS DB/DC, ASSEMBLER, PL/I

Walk-In on 31st October, 2009 between 9 am and 7 pm at:

Quality Inn Centurian Hotel
Opposite to Akaswani, Shivaji Nagar, Pune -411 005
Tel: 020 25510600
Fax:020-2552 0400

If you are unable to come on the above date, please forward your resume to jobs@dsrc.co.in

Integrare spring in un ejb 3 è possibile usando la classe SpringBeanAutowiringInterceptor. La documentazione di spring ne riporta un esempio sufficientemente esplicativo. Tuttavia se ad esempio il nostro ejb si trova in un ear con classloader condiviso (questo è il default su jboss 4.2 se non esplicitamente configurato nel jboss-app.xml come specificato nella documentazione di jboss), l’interceptor di spring potrebbe trovare nel classpath un file beanRefContext.xml di un’altra applicazione, con conseguenze inattese.

Per fare in modo che l’interceptor di spring trovi il file giusto, è necessario definire un file xml di configurazione di spring con un nome univoco all’interno dell’application server ed usare una classe custom che estenda l’interceptor di spring:

public class MySpringBeanAutowiringInterceptor
    extends SpringBeanAutowiringInterceptor {

    private static final String CONTEXT_FILE = "my-ejb-context.xml";

    @Override
    protected BeanFactory getBeanFactory(Object o) {
        return SpringBeanFactoryManager.getBeanFactory();
    }

    private static class SpringBeanFactoryManager {
        private static final SpringBeanFactoryManager instance =
            new SpringBeanFactoryManager();
        private final ClassPathXmlApplicationContext context;

        private SpringBeanFactoryManager() {
            // singleton
            context = new ClassPathXmlApplicationContext(CONTEXT_FILE);
        }

        public static BeanFactory getBeanFactory() {
            return instance.context.getBeanFactory();
        }
    }
}

In questo modo l’ApplicationContext configurato nel file my-ejb-context.xml verrà caricato una sola volta su ogni singolo nodo del cluster e sarà possibile iniettare i bean di spring nel nostro ejb 3 semplicemente usando l’annotazione @Autowired, come nell’esempio:

@Stateless
@Interceptors(MySpringBeanAutowiringInterceptor.class)
public class MyEjb {

    @Autowired
    // my spring component defined in my-ejb-context.xml
    private MySpringBean mySpringBean;

}

Last week i was running some performance tests, using an increasing number of users, without restarting my Glassfish Application Server. It occured to me at some point in time, that although my scripts were not running (taking a pause), the Glassfish Application Server was returning some interesting warnings, that immediately got my attention.

The first thing to see, was the warnings referred to the passivation of an Entity Bean. More specifically, this was the error returned:

passivateEJB(), Exception caught -> java.io.IOException: java.io.IOException

at com.sun.ejb.base.io.IOUtils.serializeObject(IOUtils.java:105)
at com.sun.ejb.containers.util.cache.LruSessionCache.saveStateToStore(LruSessionCache.java:508)
at com.sun.ejb.containers.util.cache.LruSessionCache.passivateEJB(LruSessionCache.java:433)
at com.sun.ejb.containers.StatefulSessionContainer.passivateEJB(StatefulSessionContainer.java:1784)

Caused by: java.io.IOException

Caused by: java.io.NotSerializableException: java.util.logging.Logger

Now, after carefully reading once more the lifecycle of an Entity Bean, i realised that in order for something like this to happen, the Bean must have reached it’s cache idle timeout before being moved to the pool (passivation) (default in Glassfish is set to 600 seconds = 10 minutes) . That meant  first of all, that the application using the bean, was not calling the remove method, which would have caused the EJB container to call the ejbRemove method.

I was therefore more than interested to see some statistics on the bean. So i turned to my Glassfish Administrator, hoping that i will find the option of down-drilling the Entity Beans, and checking on their status.I wasn’t very surprised to see that although the Glassfish Monitoring allows setting different levels on monitoring the EJB’s, it doesn’t really provide any “friendly” interface for “reading” the information.

So i had to go the hard way…digging in command line.

Now, it may seem difficult in the beginning, but once you know how to filter all the information (and i am also still struggling on that), it can get easier. Here is what you have to do:

1. Run “asadmin” in your console
2. type the following to list the  monitorable components for instance server:
   list –user admin –monitor server*
3. extract the name of the bean you want to collect statistics for. Let’s call it MyBean
4. type the following to collect the statistics on the bean:
   get -m –user admin *.MyBean.*

This will return a lot of statistics on the bean. I was interested in the number of created beans, running with 50 virtual users, and i wasn’t surprised at all to see this:

MyBean.createcount-count = 50

MyBean.removecount-count = 0

So i made one thing sure. A bean was instantiated for every virtual user of mine, but the remove method was never called. Point taken!

Now, i still had one question…why wasn’t the Bean able to be passivated.

Well, the secret here is that the ejb passivation fails because ejb has a Logger object and it cannot be serialized, hence the two log entries above:

at com.sun.ejb.base.io.IOUtils.serializeObject(IOUtils.java:105)

Caused by: java.io.NotSerializableException: java.util.logging.Logger

The solution here as i know, would be to make the logger transient. That way it won’t be serialized no more, and you have a “clean” passivation. But that is not the subject of the post, so if i am wrong on the last point here, please do correct me.

Cheers, and have a good night. I am still a little waisted after watching the U2 concert live on YouTube , so i’m heading home now.

Alex

Since the environment has been set up successful, the next step is to write a simple JavaEE Hello World application. Therefore we’ll use a simple Java WebStart client which which will call a stateless EJB to log Hello World. First create a new Enterprise Application Project, then an EJB Project and then a Java Web Client Project. It is mostly just clicking through the wizards. Create a class in the EJB Project, add a method printHelloWorld and call it from the Java Web Client Project. A tutorial can be found here.

Purple Mush, originally uploaded by Steph & Josh Bovell.

We never knew how much fun eating could be until watching Beth with her food. Although we started off slowly with a bit of home-made baby rice (using locally grown organic red rice called beras merah) mixed with expressed milk, it wasn’t long before Beth was after more interesting flavours and an eating utensil of her own.

Beth pretty well eats everything we put in front of her with the favourites being carrot, apple and a purple variety of the local sweet potato called ketela ungu. She quite happily eats all of her greens (so far beans, zucchini and broccoli) as well as cauliflower, pear, avocado and banana. Beth has also branched out on the cereal front with some oatmeal and just this morning tried her first weet-bix. On the advice of a couple of books we started mixing in a bit of chicken stock with her veg at lunch time a couple of weeks ago to introduce her to the flavour of meat, and just over the last couple of days we’ve started including a bit of mushed up chicken and veg casserole in her lunch. So far so good!

At first the introduction of solids into Beth’s diet didn’t seem to help on the sleeping front. Unfortunately sleeping with Mum and Dad and feeding every 2 hours as a result were hard habits to break. Amazingly though, Beth is now in her own room, sleeping fairly consistently from her 10.30pm feed through to 7am. However, the one thing we have learned over the last 7 months is that babies like to keep parents on their toes, so we are fully aware that this current sleeping arrangement could change any day!

Needless to say, between the crawling, attempts at self-feeding, and a recently developed ability to signal “I want” (slapping with an open palm) we have to admit our little Beth is no longer a helpless little baby! How and when did that happen?

Before you take the quiz, I encourage you to review the articles in the Design Pattern series.

Question 1

You are creating an application that simulates a technical support service provider. All requests are initially handled by Level 1 support and are escalated to higher levels as and when required.

via Dot Net Cube | Design Patterns – Which to use When? Take the Quiz!.

One of the cool things about EJB’s is the fact that you no longer need to do certain things, like go to the JNDI context, and search for your EJB.  You can let the @EJB tag do it for you (for example).

Writing a simple application to talk to a local EJB should be as simple as

@EJB
 private SimpleStatelessEJBLocal simpleStateless;
 ...
 simpleStateless.someLocalMethod();
 ...

But what I found was a null pointer exception.
So taking the application down to the simplest app.

• One servlet.
• One statless session bean.
• Using Jdeveloper 10.1.3.5 (I can’t use 11g as I need oc4j 10.1.3.5, I know I can get around it.. more on that later)
• One local OC4J 10.1.3.5 instance.

Deploying this application and after much playing around, the null pointer was gone, and this error remained.

[Oracle Containers for J2EE 10g (10.1.3.5.0) ]

9/10/19 16:52:14.779 SimpleTwoWEB: Servlet error
java.lang.ClassCastException: com.evermind.server.ejb.StatelessSessionDefaultLocalHomeImpl cannot be cast to au.edu.rmit.its.qas.ejb.SimpleStatelessEJBLocal

This puzzled me for an hour or so, but through an obscure post on coderanch I found the problem.  It seems that JDeveloper 10.1.3.x creates web projects in web 2.4 compliance, but in order to run DI you need to run web container version 2.5.  Testing this out, I changed the web.xml from this:

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee">

changing to…

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee"   xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"  id="WebApp_ID" version="2.5">

And like magic is worked.

Now according to two OTN Discussions:

If you have a look at the J2EE 5 spec, the classes where DI is supported are listed on page 64.

Component classes supporting injection
Servlet: servlets, servlet filters, event listeners
JSP: tag handlers, tag library event listeners
JSF: scoped managed beans
JAX-WS: service endpoints, handlers
EJB: beans, interceptors
Java EE platform: main class (static), login callback handler

OTN  Link 1

OTN Link 2

In this post Simone Chiaretta talks about the tools, components, and technologies he uses along with ASP.NET MVC to build web applications.

Maven/Hudson

The client’s team is mainly a Java oriented team, so they setup all the build server using java tools: they used Maven to build the projects and used Hudson to schedule the builds. I always used NAnt, MsBuild, TFS and CC.NET but since they already had all this place, I had to go with that. But it turned out to be a good thing: it seems like Hudson is probably the best CI server out there at the moment, and also has a lot of .NET related plugins. So this is turning out to be an opportunity to learn a new thing.

Custom Data Repository with Linq2Sql

As said, there is not a lot of editing to do. Furthermore the dashboard is going to connect to a legacy database, designed in a really (and I mean really really) strange way, and unfortunately I’ve no jurisdiction over it. So custom repository with manual mapping is the way I decided to go. Furthermore the developers in the team are not familiar with an ORM. Actually they are not familiar with IoC, MVC, HTML+Javascript and writing tests neither. I didn’t want to flood them with all that many technologies and practices all together. So I thought that ORM was the one I could skip for that project.

Enterprise Library and Unity

I always used Ninject for IoC, and Elmah for the logging, but Avanade is the company that wrote the first version of the Enterprise Library and it’s part of the internal development framework. But after all the EnterpriseLibrary is not that bad, and this way I have the chance to play around with Unity and maybe find a way to study the validation application block in order to make a client side validation provider on top of it.

AutoMapper

Even if we won’t have a lot of entities to deal with, AutoMapper will save us from writing boring mapping code. And will help the team to understand better the importance of having a model specific to each view and to keep the domain model separated by the view model.

Spark

WebForm View Engine holds too many connections with the WebForm’s world so I don’t like using it. Furthermore the developers of the team are not familiar with ASP.NET and very little with HTML/CSS, so I thought that Spark is a better solution since it is pure HTML with little customization compared to WebForm. And finally it will prevent developers from breaking the pattern including server controls with data logic in them.

jQuery

There was a bit of talking about whether using ASP.NET Ajax or jQuery, but at the end we opted for the latter. The reasons for this decision are various: we are using Spark instead of the WebForms ViewEngine, jQuery has a much bigger “add-on” ecosystem and in particular it has the jqGrid which by itself justifies the adoption of jQuery, and then the guys of the team heard about it and wanted to learn more about it.

jQuery UI

Tabs, datatime pickers, modal dialogs are all part of the Ajax Control Toolkit, but what the jQuery UI has is the unified theme: with just one line of configuration all your UI controls will look the same. And since we choose for jQuery, the ACT has never really been an option.

jqGrid

We have to implement a few grids that need to support sorting and paging: I already used this plugin before, and it’s both easy to setup and very powerful. You can browse some samples and the documentation here.

xVal

We won’t have many complex editing screens, just a one or two, but xVal is really easy to implement and I think it’s worth adding it even if there is just one field to validate.

Testing

We are not going to do TDD (or maybe we will, let’s see how the team goes first) but for sure we will write unit tests and we’ll try to test the most important features.

MsTest

Even if I prefer mbUnit, the rest of the solutions is already using MsTest so, even if it’s not my preferred testing framework, we’ll go with that.

RhinoMocks

Fortunately the other tests are already using this great mocking framework, which is also the one I used the most and that I prefer, so all good on this side.

My ASP.NET MVC stack and why I chose it.

Bonjour à tous,

La version 1.2.0 de java-commons est disponible!!!

java-commons est une aggrégation d’outils facilitant le développement d’applications Java / JEE.

Pour plus d’informations, suivez ce lien.

We have been meaning to do a post filling you in on Beth’s latest sleeping and eating habits (just quietly that’s a post you would NOT want to miss!).  However, just moments ago something happened that made tales of multi-coloured food stuffs and 8.5 hour sleeping patterns seem sooo last month.

Ladies and gentlemen, hot off the press and direct to your screens, may we present Elizabeth Jayne “Yes I can crawl now, how good am I” Bovell…

P.S. We compressed the video to a 11.5MB wmv file, hopefully you all have enough bandwidth to view it.  If you have dramas let us know as we can compress it further, it just loses quality.

P.P.S. By the way, the part where Josh says “She did it again” is not in reference to the crawling so much as Beth’s apparent knack for doing new things during the rare moments when Steph is in another room!

Enterprise Java Bean (JSR220) é um componente server-side que encapsula as lógicas de negócio, isto é, o código escrito na linguagem de programação Java, para atender os objetivos de uma aplicação.

Um módulo EJB é usado para implementar um ou mais enterprise beans em uma única unidade de implantação, isto é, um arquivo Java Archive File (JAR). Estes enterprise beans são executados em um container EJB de um Servidor de Aplicação.

Um módulo EJB pode ser usado como uma aplicação standalone, ou pode ser combinado com outros módulos para criar uma aplicação. Ou ainda, pode ser usado para prover uma funcionalidade de negócio através de um Web Service. Um módulo EJB é formado por:
. Um ou mais enterprise beans
. Um arquivo XML, que define a estrutura e as dependências externas dos enterprise beans, e descreve como eles são usados em tempo de execução.

Os módulos EJB podem ser Session Bean (stateless ou stateful) para atender um cliente ou implementar um Web Service ou Message Bean com o objetivo de atuar como um listener para um tipo de mensagem específico, como o Java Message Service.

In response to my previous post, I started to see the positive side of EJB 3 .
First, there’s no requirement on business interfaces. That’s cool. You don’t depend on container interfaces anymore.

Our first week back home in Bali turned out to be somewhat of a nervous one.  On Tuesday 1st September Beth had a convulsion while she was breast feeding.  We went to one of the hospitals here and the doctor did a thorough check-up, concluding that there was no sign of fever and that Beth was strong and healthy.  She did on the other hand recommend that we see a specialist since there was nothing obvious to explain the convulsion.  So, with Josh already in Singapore for work we decided to fly there and see a paediatric neurologist.  Fortunately we were able to get on the Tuesday night flight and, even more fortunately, we were able to see a paediatic neurologist at Mount Elizabeth Hospital (a good omen!) the next day.  He recommended that since Beth was otherwise healthy, she should have an EEG (Electroencephalogram) to make sure everything was tickety-boo with her brain.  Beth had to be sedated (an oral liquid which she did NOT like thank you very much!), then had all of the little electrodes stuck to her scalp (a procedure which took about 20 minutes).  The test involved 20 minutes of recording the brain activity while Beth was asleep, then another 20 minutes with her awake.  Beth was a little trooper and only got upset when the electrodes were coming off – completely understandable.  Thankfully, the EEG was all normal.  The doctor suggested that the convulsion may have been something related to Beth’s sleep, somewhat like our own body spasms when we are sleeping.  This makes complete sense considering some of the amazing body movements we both manage in our sleep sometimes – Josh has been known to do a back hand reo in his sleep!