News »Browse Articles »
A look inside the JBoss Embedded project
0
A look inside the JBoss Embedded project
DZone recently caught up with Andrew Lee Rubinger, core developer at JBoss who is leading the company`s EJB 3 implementation and is also heading the Embedded and Bootstrap subprojects at JBoss. Embedded JBoss allows you to run JBoss within the same JVM as a plain Java program, a JUnit test, standalone Tomcat, or even another application server -- having the ability to deploy to a more `lightweight` runtime provides numerous benefits on both the testing and integration fronts.
At the end of the interview, Andrew provides a brief demonstration of the new Embedded APIs inside the JBoss application server and how to use these to manage a range of lifecycle operations such as deploying an artifact directly into the server, testing to make sure that it works and then bringing the server down cleanly.
Andrew is also author of the upcoming book by O`Reilly Media, "Enterprise JavaBeans 3.1".
The complete transcript of the interview has been provided below.
DZone: Andrew, can you tell us a little bit about some of the work you`re currently doing at JBoss?
Andrew Lee Rubinger: Sure. Well, I came from the community. I was an application developer for quite some time working in EJB‑land; first, the EJB 2 stuff and then later with EJB 3. Now I`m primarily doing a lot of the EJB 3 development in our implementation at JBoss as well as trying to find ways to make it lot easier to test user application code.
DZone: What is the JBoss Embedded project?
Andrew: We wanted to build upon our success with the application server itself. The application server`s job, very simply put, is to abstract out a lot of the concerns that an application developer should not worry about. They should not worry about clustering, they should not worry about transactions, they should not worry about any of the nitty‑gritty details that a computer needs in order to operate efficiently. They should be worrying about their application code, which is sending emails and persisting records to databases. Again, the job of the application servers is to provide as many services they can in a very transparent fashion while allowing the developer to spend the majority of their time writing application logic. The Embedded project is an extension of this where we say, "Ok, instead of requiring a stand alone application to provide the runtime, you can provide your own runtime and we`re going to give you hooks for a deployment configuration and lifecycle API into the application server."
DZone: What are some of the challenges associated with testing in a stand alone application environment?
Andrew: The same as for testing in any remote process really. Interaction with a remote process is much more difficult. You`re seeing it as like a confined box from the outside and you don`t have a way of really hooking into the internals unless they`re directly exposed to you. Even simple things like deployment, and start and stop become a little bit difficult when you have a remote application.
DZone: Is testing really the only scenario in which I would need an in‑process application server?
Andrew: No, certainly not. If you have your own runtime and you want to be running JBoss, there`s some JBoss based services. Then you can certainly use the embedded launcher to start them in your own runtime and bring it up straight from there. It`s a good migration point.
DZone: Can you give us an overview of some of the current features provided by the JBoss Embedded project.
Andrew: Sure. From the onset the stated goal of the JBoss Embedded project has been scoped very, very small. It should be just to start and allow for deployments into the application server from an existing runtime which could be from like a test environment, like a JUnit or a TestNG. That`s our very core point right there. In addition to the core goals that we have in the Embedded project, we also have a bunch of extensions that are going to make the process a lot easier. One of them is a project called ShrinkWrap which is supplemented by the efforts of two community developers already. ShrinkWrap is a declarative archives project. It allows you to use Java code to assemble Java archives and WARs and EARs straight from code and it does it in a very abstract fashion.
What you do is you can take your resources like your classes, and your EJB descriptors and what not and put them into a virtual archive essentially and then ship that off for deployment into the embedded server.
DZone: How do virtual archives shorten the testing life cycle?
Andrew: As a developer you`re probably making up all of your classes in your code and you`re assembling them right there. It takes time to switch out of that mode of writing code and then going into making a build script, either like an ANT script or some sort of Maven assembly‑packaging step to actually make the formal archive which is going to be in probably a JAR format.........
Source:
http://java.dzone.com/videos/embedded-jboss?utm_source=feedburner&utm_medium=fee
At the end of the interview, Andrew provides a brief demonstration of the new Embedded APIs inside the JBoss application server and how to use these to manage a range of lifecycle operations such as deploying an artifact directly into the server, testing to make sure that it works and then bringing the server down cleanly.
Andrew is also author of the upcoming book by O`Reilly Media, "Enterprise JavaBeans 3.1".
The complete transcript of the interview has been provided below.
DZone: Andrew, can you tell us a little bit about some of the work you`re currently doing at JBoss?
Andrew Lee Rubinger: Sure. Well, I came from the community. I was an application developer for quite some time working in EJB‑land; first, the EJB 2 stuff and then later with EJB 3. Now I`m primarily doing a lot of the EJB 3 development in our implementation at JBoss as well as trying to find ways to make it lot easier to test user application code.
DZone: What is the JBoss Embedded project?
Andrew: We wanted to build upon our success with the application server itself. The application server`s job, very simply put, is to abstract out a lot of the concerns that an application developer should not worry about. They should not worry about clustering, they should not worry about transactions, they should not worry about any of the nitty‑gritty details that a computer needs in order to operate efficiently. They should be worrying about their application code, which is sending emails and persisting records to databases. Again, the job of the application servers is to provide as many services they can in a very transparent fashion while allowing the developer to spend the majority of their time writing application logic. The Embedded project is an extension of this where we say, "Ok, instead of requiring a stand alone application to provide the runtime, you can provide your own runtime and we`re going to give you hooks for a deployment configuration and lifecycle API into the application server."
DZone: What are some of the challenges associated with testing in a stand alone application environment?
Andrew: The same as for testing in any remote process really. Interaction with a remote process is much more difficult. You`re seeing it as like a confined box from the outside and you don`t have a way of really hooking into the internals unless they`re directly exposed to you. Even simple things like deployment, and start and stop become a little bit difficult when you have a remote application.
DZone: Is testing really the only scenario in which I would need an in‑process application server?
Andrew: No, certainly not. If you have your own runtime and you want to be running JBoss, there`s some JBoss based services. Then you can certainly use the embedded launcher to start them in your own runtime and bring it up straight from there. It`s a good migration point.
DZone: Can you give us an overview of some of the current features provided by the JBoss Embedded project.
Andrew: Sure. From the onset the stated goal of the JBoss Embedded project has been scoped very, very small. It should be just to start and allow for deployments into the application server from an existing runtime which could be from like a test environment, like a JUnit or a TestNG. That`s our very core point right there. In addition to the core goals that we have in the Embedded project, we also have a bunch of extensions that are going to make the process a lot easier. One of them is a project called ShrinkWrap which is supplemented by the efforts of two community developers already. ShrinkWrap is a declarative archives project. It allows you to use Java code to assemble Java archives and WARs and EARs straight from code and it does it in a very abstract fashion.
What you do is you can take your resources like your classes, and your EJB descriptors and what not and put them into a virtual archive essentially and then ship that off for deployment into the embedded server.
DZone: How do virtual archives shorten the testing life cycle?
Andrew: As a developer you`re probably making up all of your classes in your code and you`re assembling them right there. It takes time to switch out of that mode of writing code and then going into making a build script, either like an ANT script or some sort of Maven assembly‑packaging step to actually make the formal archive which is going to be in probably a JAR format.........
Source:
http://java.dzone.com/videos/embedded-jboss?utm_source=feedburner&utm_medium=fee
