Hi Ales,

There are many ideas in the listed threads. For me to create testable ejb code is the biggest issue. Some of the ideas and problems I will solve in my next customer project:
-test ejb3 code. The first test looks like if this can be easily done with embedded jboss

-test ejb2 code. In my first test I made a dirty patch in org.jboss.ejb.EjbModule. Now it works.

-separate predefined configurations from the embedded jboss core. We actually create some configuration maven artifacts. Now we test if we can use the configuration in our test projects.

-make all ports configurable. We have the problem that the test fails sometimes if another test is using this port. For that I will change the BaseTestCase or build a new one. In environments with ci servers is this very important.

-support testng. We actually discuss if it is easier to use a testng dataprovider or factory instead of changing the BaseTestCase.
-remove org.jboss.embedded:thirdparty-all dependency. Better would be a pom which contains all dependency, so that I can see maven problems in dependency.

These are the themes which will play a role in my project and I would be glad to give some work back.

Another important thing is the support of the forum jboss user / embedded JBoss. This is linked in the wiki and there are not many new answers.
I could try to start the first level support and to find out if this is a known problem or to support the user in the first steps. Further I could create a test case and try to solve problems, discussed in the forum. Jboss 5 is new to me, so it could be that I will need some help by solving the problems.

These are my ideas to support the project.

What do you think?

Regards Philipp

Some design goals I'd like to see:

* Separating out Embedded from monolithic to component-based structure a la EJB3. (Ales mentioned this, I'd like to also add a "Maven Integration" project to house some custom plugins).

* Focus on writing *as little as possible* code for Embedded, extracting out from AS wherever possible.

* Keep scope for Embedded project itself very limited. The goal here is to remove the runtime and allow AS to run in a host VM/Classloader.

* Take advantage of Service Binding Manager

* Focus on small, frequent deliverables. With AS5 as a main priority we'll either get overloaded or Embedded will take a permanent back seat if we bite off too much.

In the short term, let's get organized:

* Create a Roadmap / Featureset on Wiki

* Do a gap analysis on what's already in place vs. what we'd like to see

* Throw some calls for suggestions to the community via blogs

My guess is that we'll be looking to Ales to lead the charge?

S,
ALR

Hi,

I like the idea to create a roadmap / feature set, where all ideas of the treads are collected. Then can we discus about the priority?

Sorry, jboss wiki is completely new to me. Could anybody create a page that fits to naming concept of jboss?

Regards Philipp

Hi,
This is a first idea how the wiki page could look like.

Design guide lines / goals:
- Separating out Embedded from monolithic to component-based structure a la EJB3. (Ales mentioned this, I'd like to also add a "Maven Integration" project to house some custom plugins).
- Focus on writing *as little as possible* code for Embedded, extracting out from AS wherever possible.
- Keep scope for Embedded project itself very limited. The goal here is to remove the runtime and allow AS to run in a host VM/Classloader.
- Take advantage of Service Binding Manager
- Focus on small, frequent deliverables. With AS5 as a main priority we'll either get overloaded or Embedded will take a permanent back seat if we bite off too much.

Use cases:
- Embedded jboss for extending other servers'™ functionality (Tomcat, Jetty, Glassfish, )
- Enable easy testing of EJB's (2 and 3)


Features / wish list:
-Supported environments
- Tomcat
- Jetty
- Glassfish
- Supported application
- Seam
-Testing
- Provided test configurations for testing, also the possibility to have a configuration
artifact and some additional configuration in the tested artifact like data sources.
- Cactus tests for Tomcat and seam integration
-Build management / release management
- Provide thirdparty pom instead of org.jboss.embedded:thirdparty-all
- Enable the test in the main pom
- Split the embedded project into smaller projects. For instance:
- core
- test helper
- configurations (ejb3 only, ejb with mdb, ejb 2 and 3 supported)


In my customer project we use embedded jboss mainly for testing. I would like to give some experiences and code back to the community. In the project we have more then 100 ejb artifacts. Most of the artifacts contain ejb 2 code. We stated to create test configuration artifacts for ejb2 and 3. We had some problems to test ejb 2 beans. After the change of two jboss classes it seams to work. We created a maven project that uses the jboss artifact and add our patch to switch to newer versions easier.

Another topic I think is how to create testcases with easymock or jmock. So far I know they are not able to support to mock annotations. So it is not easy (possible) to write an ejb3 that uses the nice mock frameworks. If somebody knows a solution, this could be a good topic for a tutorial.

What do you think, how I could support the project?

And how can I send some patches?
For instance I would like remove the source and resource directory in the pom. It points to a wrong directory. After removing the block:

<sourceDirectory>src/main</sourceDirectory>
<resources>
 <resource>
 <directory>src/resources</directory>
 </resource>
</resources>

Hi,

At the weekend I had a deeper look to the embedded jboss sources. I think the first we should do is to get the provided tests running. What I found out:
- In the trunk version of jboss server the mbean jboss.security:service=AuthorizationManager is removed. Solution is to remove this mbean in jboss-services.xml
- the configuration is located at src\main\resources\javase. If we would move this to src\main\resources the configuration will be found by the maven tests.
- Many dependencies for testing are missing. I started to fix each ClassNotVoundException step by step. But dependencies are still missing. I added the following list to my pom:

 <dependency>
 <groupId>jboss.jbossts</groupId>
 <artifactId>jbossjta-integration</artifactId>
 <scope>test</scope>
 </dependency>
 <dependency>
 <groupId>jboss.jbossts</groupId>
 <artifactId>jbossjta</artifactId>
 <scope>test</scope>
 </dependency>
 <dependency>
 <groupId>org.jboss.transaction</groupId>
 <artifactId>jboss-jts-common</artifactId>
 <version>4.3.0.BETA2</version>
 <scope>test</scope>
 </dependency>
 <dependency>
 <groupId>javax.xml.bind</groupId>
 <artifactId>jaxb-api</artifactId>
 <scope>test</scope>
 </dependency>
 <dependency>
 <groupId>org.jboss.jbossas</groupId>
 <artifactId>jboss-as-server</artifactId>
 <scope>test</scope>
 </dependency>
 <dependency>
 <groupId>org.jboss.jbossas</groupId>
 <artifactId>jboss-as-varia</artifactId>
 <scope>test</scope>
 </dependency>

 <dependency>
 <groupId>javax.xml.bind</groupId>
 <artifactId>jaxb-api</artifactId>
 <version>2.0</version>
 </dependency>

 <dependency>
 <groupId>javax.xml.bind</groupId>
 <artifactId>jaxb-api</artifactId>
 <version>2.1</version>
 </dependency>

Its all about unit testing for my team. Our app is a mixture of JMX (dynamic) MBeans and EJBs (3). We are not using Seam. Project is Maven 2 based. We intend to do extensive unit testing inline with the Maven build (out-of-container testing) on ALL code.


Specific out-of-container test patterns we need supported.

1. MBean in isolation.

Pretty easy. Unit test code just simulates JMX container calls to MBean lifecycle methods to start/stop the MBean, etc.

2. SLSB in isolation.

One of our SLSBs wraps all our JPA operations. Currently we are able to make this work (SLSB/JPA) using EJB3Unit, but its docs are poor and project has little community support. We have done some initial reading re: OpenEJB3 and GlassFish maybe being a better alternative.

3. MBean calling MBean(s).

Completely blocked here. My guess is that, unlike service beans, dynamic MBeans can not use JNDI to obtain instances of other dynamic MBeans. MBean must call JBoss JMX server to locate called MBean. No apparent way to support this out-of-container (JMX server).

4. MBean calling SLSB(s)

We are able to fake this out via stuffing JNDI with a mock SLSB. Test setup again simulates JMX lifecycle in instantiate MBean, which then is able to get to the SLSB mock via the stuffed JNDI.

5. SLSB calling MBean (s).

EJB3Unit is able to instantiate the SLSB. Again, we simulate JMX lifecycle methods to create the MBean instance, then inject it via a direct call to a property setter. Note that this means we must use property based injection for DI (not a problem).

-----------------


2 and 5 are problems because embedded container would not work, EJB3Unit is barely sufficient.

3 is a problem because it seems a dynamic MBean, unlike a SLSB, can not use DI/JNDI to get an instance of an other dynamic MBean? I believe 3 goes away if we were using @Service beans, but then we would not be able to manipulate MBean meta data (operation and attribute descriptions, validation on attribute settings, etc... we developed several Java 7 like annotations for our MBeans).