jEmbedded F.A.Q

First of all thanks to the people who have sent me emails asking about jEmbedded and of course to those who like it :)

All the feedback are highly appreciated so I can improve it in the next versions.

I reckon that the documentation now is quite scarce but I wanted to release before I went on holidays (I will improved it a lot though) so I did that compromise. Also there are some features that are not explained in the provided documentation (many actually)

So I will try to answer here some of the questions I have received.

* What is this framework good for?

Well first of all it's just an IoC container with all that implies, but more importantly it allows you to manage your application elements (definition, creation, composing, starting, stopping, releasing) in a easy and fast way (using annotations, no need of XML or other additional configuration).

It provides the semantics or annotations needed to promote a bean or a POJO to a service, to a component, or to a entity managing their life cycle (if you choose that). For example, the container will start and stop the services for you.

These additional semantics provide not only a life cycle to the POJOS, or a contract but also additional features as accessing to the executing environment and a chance to be externally managed (through JMX, I'm already working on a console).

I would say that the provided embedded services and the feature of easy composition (creating a new service using other services) it's quite useful. In fact, it's how this framework was born.
For example, you can get the jetty-service and create and web server of your own using just composition. Or a rules-server for your application using the rules-service provided, executing a set of business rules for the rest of the services.

Finally, jEmbedded is an implementation of another framework of mine, jRepository that allows you to create your own IoC customized container (included in the distribution).


* Can jEmbedded be used in a web application?

Of course you can, in the same way you would use it in a standalone application. (I designed it with the 2 environments in mind). You have to be careful though, in the way that the container are created or disposed. This is managed by the annotation :

@Container(ContainerInstanceType instanceType)

public enum ContainerInstanceType {
SINGLETON_VM, PROTOTYPE_VM, PROTOTYPE_BY_THREAD;
}

If you don't provide this annotation by default the way of creating instances it's PROTOTYPE_BY_THREAD (a new instance per thread) so if you are creating an instance of jEmbedded inside a MVC Controller, there is a good chance that you are creating a new container with each request. In this case use the SINGLETON_VM property to have one container per VM.

Another way of getting the handler to the container is using the following static method:

EmbededHandler handler = ContainerHolder.getCurrentThreadContainer();

jEmbedded-0.1 - Release

Well at last!,  after 6 months of work (well just a bit everyday, more the weekends) I'm ready to release a very complete first version of jEmbedded.

jEmbedded bornt out of the necessity to use an IoC container on the go, lighter, faster and easier. Spring is great, but it takes some time to setup all the beans, xml-schemas (also you can use annotations, but still). For my purposes, using embedded services or just services  it was a bit too much,  and I wanted just to provide some annotations, some configuration data and get it running.

In fact, it was the core of the first version of my testing framework (jIntegration-Test), but I found myself writing a lot of xml schemas for each service or association classes something I wanted to avoid for the sake of simplicity.

What is more, I was looking for something more specific and Spring or  Guice are very generic,  everything is a POJO for then. I wanted to have more control of my services and have different kind of POJOS:

* Services (CMT / Unmanaged)

- Lifecycle is managed by the container or not.

- Can be started / stopped. Initialized / disposed.

- The context is injected by the container and gives access to the running enviroment. 

- A service could contain and manage services, components, beans and entities.

* Components (CMT/ Unmannaged)

- Lifecycle is managed by the container or not.

- Can be initialized / disposed.

- The context is injected by the container and gives access to the running enviroment. 

- A component could contain and manage components, beans and entities.

For example, A CMT Service. This service will be started and stopped by the container. Also initialized and disposed.

@AnnotatedService(id="testService", resources=TestBean.class) 

public class TestService extends AbstractCMTService {  

@Inject  

private TestBean testBean = null;  

public void test() {  

testBean.printMsg();  

} 

}

In order to have access to the service and get the container started:

EmbeddedHandler handler= EmbeddedHandlerFactory.getInstance(TestService.class); handler.start(); 

TestService testService = (TestService) handler.getService("testService")

testService.test(); 

handler.stop();

As you can see, my main concern has been keeping it easy and fast to use as it should be with embedded services.

More information will be found in the project homepage.

jembedded-0.1-release

jIntegration-Test-0.9.3-SNAPSHOT version released.

jIntegration-Test-0.9.3-SNAPSHOT

User Guide

jIntegrationTest - version 0.7.1 notes.

As I've just released the 0.7.1 version of jIntegration-Test (aka JEmbedded) I though I should write down some brief notes about it.

First of all I've changed the name to something more intuitive than jEmbedded because it's main purpose its integration testing (even thought is based on the concept of embedding servers).

Secondly, this is still a work in progress so in every version I'm releasing I'm changing many things: refactoring out code, adding new features, refactoring configuration files, adding new services... etc etc.. always having in mind how to make it easier to use.

So expect more changes and new functionality like more testing methods for every integration test unit. For example, a test method for every HTTP result code: 500, 400..

Of course working this way has some drawbacks but I think it's worth the effort.

The last integration unit I've added is one to test JMS applications using an ActiveMQ embedded server. At the moment you can test destination creation, sending messages etc.. expect more functionality for this integration unit.


@JMSIntegrationConfigurationTest( connector = "tcp://localhost:61666",
jmx = "false")
public class EmbeddedJMSIntegrationTest extends AbstractJMSIntegrationTest {
public void testDestination() {
testDestinationCreation("TEST.TEST", "tcp://localhost:61666");
}
}

Despite all of that, still it's quite functional and I'm using it myself at the moment in real life projects with a degree of success.

In this release I've put some extra care and effort to release something you wouldn't have any problems to compile and use. In order to do that, I've included all the dependencies that you can't get from a external mvn repository. Just copy the folder into your own mvn repository.

Also in the src directory you can find a ready to compile and install project.

Any problems, just drop me and email or leave a comment here.

You can read the complete installation notes in the project's wiki.