jembedded-0.1.3-Release

Hi all,

I'm very pleased to announce that I've just released the
jEmbedded-0.1.3 version.

It's much more that a collections of fixes from the previous RC
versions as I have included some features that was intended for the
0.2 version (or higher), but it gives a good preview of the future
direction of the project. In fact I though to label this one as 0.2,
but I didn't for consistency.

There are 5 very important features included in this release:

- Annotation inheritance: Now you can extend any of the core
annotations (@AnnotatedService, @AbstractAnnotatedService...) to
create you own annotations. This means that you can set up your
services directly using annotations like if you were writing and xml
bean in Spring:

Until now you were doing this (still you can of course):

@AnnotatedService(id="service", resources={WebClient.class})
public class Service extends AbstractCMTService {

@Compose(ref="webClient")
private WebClient webClient;

@Inject (value=${service.url})
private String url;

}
}

Now you could do this:

public @interface CustomAnnotatedService {

Class inherits() default @AnnotatedService; // the annotation you
want to extend.

//now you override the attributes you'd like to use (this case from
the @AnnotatedService(id, lazy clazz, etc..),
// the ones that are not overriden will be taken from the parent.

String id() default "service";

String clazz() default "org.jsemantic.jembedded.Service";

Class[] resources() default {WebClient.class};

//new attributes
String url();

}

Now the service looks like this:

@CustomAnnotatedService(url="http://code.google.com/p/jembedded")
public class Service extends AbstractCMTService {

@Compose(ref="webClient")
private WebClient webClient;

@Inject (value=${service.url})
private String url;

}

Now you can reuse this new annotation whenever you like.

The inheritance mechanism can be used with the core annotations
(AnnotatedService, AbstractAnnotatedService, AnnotatedBean,
AnnotatedComponent..).

If you have a look at the source code or to the examples you will see
that I have refactored the code to use this feature when it fits.

- @AbstractAnnotatedService

This is a very and a powerful feature that also will give you an idea
of the future direction of the framework. Now you can create a Service
using an abstract class (similar to the @AbstractService) without
needing to extend or implement anything (not even the Service
interface). You can mix regular and abstract classes and injecting or
composing fields.

This is the old example of WebServer refactored to use the new
features (also custom and inheritance annotaions).

@AnnotatedWebServer
public abstract class WebServer {

@Start
public void start() {
getJettyService().start();
}

@Stop
public void stop() {
getJettyService().stop();
}

public void setPort(String port) {
getJettyService().setPort(port);
}

//Composition, WebServer will handle the jettyService lifeCycle
@Compose(ref="httpService")
public abstract JettyService getJettyService();

@Compose(ref = "propertiesService")
@PropertiesService(propertiesFile="META-INF/web-server/web-
server.properties")
public abstract
org.jsemantic.jirepository.core.services.properties.PropertiesService
getPropertiesService();
// end of service composition

//Added functionality, you can create dynamic invoking methods from
any service
//that you may have in the container
@ImplementedBy(ref="httpService", refMethodName="getServerContext")
public abstract ServletContext getServletContext();

}

If you read the code you would notice:

- The abstract methods are implemented in real time, so you can use
then in the regular implemented methods.

- There are 2 new annotations @Start and Stop that replaces the old
startService and stopService.

- The service can be cast to Service (even though it does not need to
implement it).

- If you like the PropertiesService can be declared at class level,
this is just a choice, you have as much freedom as usual.

- @Compose new annotation: works like @Inject, but ties the lifecycle
of the composed service to the parent Service, not the container. In
other words, the composed service will be started and stopped by the
parent service. For example, if you declare the propertiesService at
class level the propertiesService will be handled by the container,
nor by the WebServer:

@AnnotatedWebServer
@PropertiesService(propertiesFile="META-INF/web-server/web-
server.properties")
public abstract class WebServer {

@Start
public void start() {
getJettyService().start();
}

@Stop
public void stop() {
getJettyService().stop();
}

public void setPort(String port) {
getJettyService().setPort(port);
}

//Composition, WebServer will handle the jettyService lifeCycle
@Compose(ref="httpService")
public abstract JettyService getJettyService();

}

In the case of the jettyService it makes sense its lifecyle it's tied
to the WebSever but you can also do this:

@AnnotatedWebServer
@PropertiesService(propertiesFile="META-INF/web-server/web-
server.properties")
public abstract class WebServer {

@Inject (you can use Compose here too), here the container will
handle the jettyService
private JettyService jettyService;

@Start
public void start() {
jettyService.start();
}

@Stop
public void stop() {
jettyService.stop();
}

public void setPort(String port) {
jettyService.setPort(port);
}

//Added functionality, you can create dynamic invoking methods
from any service
//that you may have in the container
@ImplementedBy(ref="httpService", refMethodName="getServerContext")
public abstract ServletContext getServletContext();

}

As you can see you have a lot of freedom to compose or create new
Services with the new features, you can annotate at class, method or
field leve, using abstract or regular methods.

You can also provide a interface for the service if you like or need
it.

The @AnnotatedWebServer ann looks like this:

public @interface AnnotatedWebServer {

/**
*
* @return
*/
String id() default "webServer";

/**
*
* @return
*/
Class inherits() default AbstractAnnotatedService.class;

/**
*
* @return
*/
Class[] resources() default { JettyServiceImpl.class };

}

- Integration testing framework integrated within the container and
services (jIntegration therefore is depecrated):

I've always felt that the testing process should be more integrated
into the development process so what I did was to include the testing
framework within the core framework and the services so now it's
availble at any time (I left the jUnit4 dependency optional though).

So basically now the core framework has an Assert class with some
useful classes and the same happens with the services.

For instance the core has Assert.getService(), Assert.existService()
and so on.

In order to setup a unit test class (or integration test class) you
need to use @Container and the @RunWith annotation. Keep in mind that
the Asserts are static classes so the created container must be
attached to the current thread, so you need to use the
prototype_by_thread annotation.

@RunWith(IntegrationTestClassRunner.class)
@Container(instanceType=ContainerInstanceType.PROTOTYPE_BY_THREAD)

@WebClient
@Include(resources=WebServer.class)
public class IntegrationWebServerTest {

//dispose the container between test methods invocations, if you want
to reuse the same within invocations, delete this method
@After
public void dispose() {
ContainerHolder.releaseCurrentThreadContainer();
}

@Test
public void test() {
WebServer server = (WebServer)Assert.getService("webServer");
assertNotNull(server);
}

}

As you see you don't need to create a container yourself,one will be
created for you by the testing framework.

- Ruby now it's a separate service and services can be fully
implemented with it. Have a look at the new CalculatorService example
that mix a complete ruby service with a java one.

- New Spring AOP Service.

- Core and services Refactored.

I have refactored some parts of the core but I will work more on this.
The services and annotations have been refactored as well and adapted
to the new features.

- Examples and case study.

I have completely refactored them and adapted to the new features,
trying always to simplify as much as possible.

The case study has been completely refactored and simplified (I have
removed GWT in this version), usign the new features and services. I'm
writing a complete paper about this, but I think you will find easier
to understand this time.

- RoadMap

As you can see a lot of effort has been put into this release, not
only to improve the past version but to look to into the future.
The @AsbtractAnnotateService and the annotation inheritance are 2
powerful features and examples of this. The idea is to implement all
the services and elements without any asbtract class (like
AbstractCMTService) and make the services more intelligent.

- Versions 0.1.3 to 0.2 - Maintenance and fixes. Improve Services and
examples . Complete documentation.

- Versions 0.2 ->1.0 - New features (removing the need of abstract
services etc) and new services. More scripting languages.

As I'm designing the new versions, please any features you think it
would be nice to have please let me know.

Special thanks to all of you that downloaded jEmbedded and helped me
to improve it. Your comments are always appreciated.

I will dedicate the next few weeks to upto date the documentation.
Please be patience, I promise I will do it :)

jEmbedded - 0.1.3. RC-1 - Weekend Release

Hi,

Yes I know I've skipped 2 versions :) but the work has been progressing so well that I decided to wait a bit and release something more complete.

So I'm releasing a rc this weekend, it's still a bit rough on the edges but it contains most of the features that I'd wanted and works pretty well. Also it will fit with the new documentation that I''m going to start writing this weekend as well.

New features:

- Dynamic Injection/creation of Services: create services just with an
interface + annotations, no implementation neded, in case you are
just composing services:

@Repository(id = "serviceLayer", iocProviders = { "springRepository" }, parent = "persistenceLayer")

@AnnotatedService(id = "serviceLayer", resources= {InvoicingServiceImpl.class})

public interface ServicesLayer extends Service {

@Inject(ref="invoicingService")
public InvoicingService getInvoicingService();

@SpringRepository(configurationFile = "META-INF/invoices-app/layers/ persistence-layer.xml")
public Service getSpringRepository();

}

- Complete Spring integration: a service exporter (from jembedded) into the spring context, @Inject can reference a spring bean, a @SpringProvider annotation that will load a context as a service and can be referenced as well., a ContainerListener for web applications..
etc etc..

- More services: Validation-Service (using annotations, oval), dao-service, hibernate-service, agent-service, proxy-service.

- A payload validator for mule using the the validator-service, so you can validate your payload with annotations.

- More examples including an esb/integration case study including spring/spring-mvc, jms, mule, rules etc.. I think it shows very well what you can do with jEmbedded. Also it's an original cas study, it's not the typical aggregator of responses you can find all over the net.

- jIntegration-Test 1.0 (see the web services post).

- Fixes and more stuff.

Well I think it's pretty good for this version.

Adolfo

And after the holidays...

I resumed my day job this last week and it wasn't very bad :) at all . So this weekend I resumed my work on jEmbedded. First of all, thanks to all the people who took the time to try it and sent me their comments, you have helped me a lot. Even though it was a early release it has given me a lot of insight in which direction I should go.

I decided to release the version 0.1.1 in the next few days that will be focused in:

• Improved Spring Integration: The @Inject annotation will be able to reference a Spring Bean and more.
• Improved Documentation.
• Improved Web Support.
• More examples: I'm adding several examples that I'm working on as a complete example of a Invoicing System including Spring MVC integration and a hierarchical services layer (you can have an early peek on the project website). That will show a lot of the jEmbedded features as creating and composing a service layer in a few minutes. Other examples will include jIntegrationTest-0.1, how to package services with jEmbedded etc...
• Bug fixes and code refactoring.

jEmbedded - FAQ III

Well I'm going abroad for my holidays (it's time at last !!) so I won't be writing in a while.

I've just created a new discussion group jEmbedded Discussion Group so you are free to join and post your questions, requests etc...

After holidays want I'm going to do it's to write down a full documentation and upload more examples.

In the meantime here it's more Q/A:

* What's the difference between the @Include and @Repository annotations?

With these two annotations resources can be added to the container but in a different manner as @Repository will create a new container for the resources and @Include will just add them to the current container (default container in case you haven't provided the @Repository ann).

Use @Include if you only want to add some extra resources to the container and not to create a new one.

* Spring Integration, how to do it?

There are many different ways to do this. I've provided a spring-support-module that will help you, but in this stage it's not very comprehensive as I've focused to provide a stand alone IoC container.

In this module a FactoryBean class is provided so an instance of the embedded container can be stored into the spring-context. Then you can inject the container in any bean you want, get the container from Spring or just use ContainerHolder.getCurrentThreadContainer().
Please have a look at the spring-integration-module and the embedded-database example for more information.

You may ignore the integration module and write your own FactoryBean:

@Container(instanceType=

ContainerInstanceType.xxxx)
@Repository(id="database-service-layer", resources={EmbeddedDatabaseImpl.class})
public class EmbeddedDatabaseFactory implements FactoryBean {

public Object getObject() throws Exception {
return EmbeddedHandlerFactory.getInstance(getClass());
}

public Class getObjectType() {
return EmbeddedHandler.class;
}

public boolean isSingleton() {
return false;
}

}

Then you can retrieve the container like this:

ApplicationContex appContex; //SpringContext

EmbeddedHandler handler = (EmbeddedHandler)appContext.getBean("factory-bean-id");

Finally, you can create the container in any spring bean you'd like. Of course watch out what kind of bean it is (singleton, prototype etc...)

* Can the annotation @Inject be used to reference a Spring bean?

No at this moment, but you can inject the container to any spring bean or just accessing the container with ContainerHolder. I will add this feature in the near future.

jEmbedded FAQ II

Here there are more questions that I kept being asked about jEmbedded:

* What's the best way to use jEmbedded in a web environment?

Depends on how are you planning to use the container as a singleton, prototype or instance by thread.

Singleton

If you are planning to use it as a one single container to serve the whole web app you can create and dispose the instance in a ServletContext listener:

import javax.servlet.ServletContextListener;
import javax.servlet.ServletContextEvent;
import javax.servlet.*;

@Container(instanceType=SINGLETON_VM)
public class EmbeddedContainerListener implements ServletContextListener {
{
private ServletContext context = null;

private EmbeddedHandler handler = null;

public void contextDestroyed(ServletContextEvent event)
{
this.context = null;
handler.stop();
}

public void contextInitialized(ServletContextEvent event)
{
this.context = event.getServletContext();

handler = EmbeddedHandlerFactory.getInstance(EmbeddedContainerListener.class, *.class);
handler.start();
}
}

In order to access the container from any part of the web app:

EmbededHandler handler = ContainerHolder.getCurrentThreadContainer();

If you are using Spring, you can use an implementation of the ContainerListener to create the contaner.

As an instance per thread.

Let's say that you need a fresh container per request, in a MCV controller for instance. In order to do that just create and dispose the instance there.

Prototype instances.

You can create and dispose these instances anywhere but remember to dispose them!


* What are the differences between @Container and @Repository annotations.

@Container is just an annotation to control how the instances are being created when EmbeddedHandlerFactory.getInstance() is invoked.

@Repository is a way to create logical collections of services, components etc, for example different layers of services or components (as you can create them as a hierarchy).

This is useful even when you don't want to create complex collections (as a tree of services) just as an entry point for the container:

@Repository (id="baseServicesRepo", resources={*.class})
public class RepoEntryPoint {

handler = EmbeddedHandlerFactory.getInstance(RepoEntryPoint.class);
...
}

Now for instance lets say you need to create a different group of services that need to reference the former repository for composition:

@Repository (id="extendedServices", resources={*.class}, parent="myRepo")

Now the new container would have access to the to the parent repository as well.

I will be creating a full documentation in September, some web support out of the box and more examples (after my holidays).

Any feedback and comments are welcome.

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.

jIntegrationTest Framework.

The Framework.

jIntegrationTest comes from my own experience working in many projects and trying to figure out how could I do the integration tests easier. Usually you will find two approaches: using mocking frameworks or just deploying the application and testing it.

The Mocking Approach.

One approach is using one of the many *.Mock.* frameworks out there. It's a valid one and it works (easy for POJO's, no that easy if you want to mock something more complex as HTTP request for example) but you probably will found yourself writing a lot of code and spending a lot of time just to replicate the behaviour of the application.

Mocking as you are developing and designing it's OK, as you don't have the actual code or HTML's or pages (that's the whole point of mocking). But at the end of the day, when you have the real code it feels lacking doing the integration testing through all that mocking infrastructure as you are not getting most of the real errors you would get in the real environment (application, system, configuration, environment, dependencies errors etc...). The good thing about this approach is that fits easily with automatic testing and continuous integration.

Just Deploy and test Approach.

The other approach and sadly the most common one it's just doing the deployment and see what happens. OK the deployment fails because the XML descriptors are wrong or a file it's missing or we are getting a null pointer. Fix it, compile, test and deploy again. And so on. At last the deployment works, start testing the application, now one SQL sentence is failing. You do it again.. and again :). Now everything seems to work but now one new component is added and the deployment process fails again :(.

Well it's clear how many time it's wasted following this approach and what is worst, you are never sure that you are not breaking something when you add something new having to do expensive regression tests. It's obvious this approach it's no very easy to automatize.

Why to use Embedded Servers and jIntegrationTest.

At this point it's when the idea of using embedded servers (and of course jIntegrationTest) comes handy as you won't have any of the problems of the former approaches:

• Don't need to replicate the behaviour of the application, just test the expected real results, being a number, a HTTP response, the creation of a component...
• Don't need to deploy the application to test it, just run the the integration test units from Eclipse, maven, ant etc.. getting an instant feedback.
• Don't need to do regression testings as the process can be automatized.

The advantages of using jIntegrationTest are:

• You get all the above advantages.
• Many embedded servers out of the box: HTTP (Jetty), DB (HSQLDB), Web Services (Apache CXF), Spring (Container and MVC), JMS(ActiveMQ) and RMI.
• Easy configuration relying on defaults and annotations (almost none).
• Based on JUnit so it's very easy to get into.
• Many Integration Test Units out of the box: HTTP, DB, Spring, Spring MVC, JSF, Web Services....

A quick example

You can find the complete application and tests in the folder examples/invoices of the jIntegrationTest release.

@HttpIntegrationConfigurationTest( port=9006, root="/test", src="src/main/webapp/")
public class InvoicesControllerTest extends AbstractIntegrationHttpTest {

public void testController() throws Exception {
String uri = "http://localhost:9006/test/invoice.do";
assertResponseStatusOK(uri);
}
}

In this test we are testing an actual controller of the application which is responsible of invoking a service that calculates the invoice.

As we are testing a controller we need to use a HTTP embedded server, which configuration it's very easy, just need a port, a web root and the root location of the web application in your file system.

It's just a simple test in which the framework will execute a request to the indicated URL, in this case the invocation URL of the controller, just if someone would have pressed a button to generate the invoice. If the server returns an OK (200 code) the test will pass.

Of course, if there is any problem in your web application you will get an error and you could fix it right away without having to deploy again.

New Frameworks and change of direction

Once again it's been a long time since the last time I wrote something here, mainly because I thought was much better to invest the time writing code and new stuff. There are already many good blogs out there commenting the new stuff, enough to keep you occupied for ever.

So I decided to focus on my new frameworks and comment some other interesting stuff from time to time.

I've been working mainly in two new frameworks and the reworking of jServiceRules:

• jiContenedor: Multi layer JEE Service Container based on Spring, containing many different services out of the box: Validation (OVAL) , i18n, Logging, Spring/GWT MVC, JMS, jCaptcha, Spring Security, WebServices, Rules (R4Spring). It allows to define different layers for your applications (for example): web layer, repository layer, integration layer, services layer and so on. Relies on default configuration and a mix of xml schemas and annotations.

• jIntegrationTest: JEE Integration Testing Framework including HTTP, DB, JMS, WebServices, RMI and JMS embedded Servers. Includes several Integration Testing Units: HTTP(Jetty), DB(HSQLDB), JSF, JMS(ActiveMQ), Spring, Spring MVC, Apache CXF WebServices...
• Rules4Spring: evolution project from jServiceRules, focused on using declative/sematic rules in Services, using annotations.