[jboss-dev-forums] [Design of POJO Server] - Re: Proper definition of embedded jboss

[bill.burke@jboss.com]

http://wiki.jboss.org/wiki/Wiki.jsp?page=EmbeddedJBoss

Use cases in order of importance (in my opinion):
1. Junit testing "outside" of application server.  This means making it as easy as possible in IDE's to right click on a set of unit tests and just run them from the IDE without any special IDE plugins

2. Small lightweight SE apps that can boot quickly and in which the app developer controls directory structure, and bootstrapping.

3. Tomcat integration and abstraction.  Ability to provide JBoss projects a la carte to Tomcat.

4.  App server abstraction.  Framework to provide other JBoss projects with an easy way, common way to plugin into other application servers.

If you look at the embedded project, there's really not much code.  A lot of it is to work around old JMX Microcontainer issues, or issues with Tomcat.  This codebase should be getting smaller, faster, and simpler over time as we convert older jboss projects to use the new kernel   

API:
There's only a few exposed APIs.  Specifically a bunch were written that ease-of-use wrappers around the MainDeployer to provide a programmatic API for users to this service. Specifically:

org.jboss.embedded.Bootstrap
org.jboss.embedded.DeploymentGroup

There's also VFS apis that should be exposed and supported, specifically the:

org.jboss.virtual.plugins.context.vfs.AssembledContextFactory;
org.jboss.virtual.plugins.context.vfs.AssembledDirectory;

 
CONFIGURATION:
Configuration should be no different than JBOSS AS, except that maybe we don't want to ship with the profile service or management layers.  (Also, see refactoring comments below, specifically point #7


TESTING:
I also worked on an extension to JBoss Test framework that could take existing JBoss unit tests and run them within embedded.  This worked by subclassing existing Junit tests and running with the embedded container.  Of course, you couldn't work with tests that required non-jar file formats or special classloading features as embedded is supposed to work in the environments classloader.  As many of these tests should be converted so that we are sure various JBoss components do not require special app server configurations.

WHAT REFACTORINGS SHOULD BE DONE:
The embedded project should be a very small project.  If the rest of JBoss is designed correctly, the embeded project should really just be a packaging and integration project.  Integration being whatever bridges that need to be built to environments we want to run in.

IMO, most of the refactorings that should be done are not within embedded.  

1. Gut the requirement for special protocol handlers for URLs (i.e. "vfsfile:", "resource:").  What sucks about the JDK is that once the URL Handler factory is set, you can never unset it.  This required me to hack Tomcat to allow our deployment system to work.

2. For the VFS provide default behavior for when it doesn't recognize a URL protocol.  Like, for instance, following the rule of if the URL ends in "/", then abort, if not, treat the VFS root as a JAR.

3. Allow injectable MBeanServer.  Currently, we have a hard dependency on the JBoss JMX implementation mainly because  we put JBoss specific mbeans within private JMX namespaces (like the MBeanRegistry).

4. Move old services over to the new kernel and beans.xml format wherever possible.

5. Improve bootstrap times.  Previously 20% of embedded boottime was within all the JAXB shit you guys do.  Would be cool if we could precalculate and persist models at build time, rather than at runtime.

6. Refactor Seam so that it as a JBoss Kernel deployment component.  This is going to become more and more important as we get to the deployment model we want to get to.  That is, a model where you just throw a bunch of shit in your WEB-INF/lib or classpath and everything just works.

7. Seam is an interesting model in that everything is turned on by default (they have to do this model because all their services are defined using annotations).  To turn things off you explicitly turn them off within a configuration file.  If you want to tweak a service's default configuration, you again, have to do this in a specific central configuration file.  WHY IS THIS A GOOD THING?  Well, if JBoss MC allowed this, the Embedded packaging could be just everything JARRED up in one jar that is put in the user's Classpath.  No exposed configuration files or directory structure.  If the user wants to turn off/configure things, they just add a bit of configuration to the area's they are used to tweaking.

INTEGRATION PLUGINS:
* SE (already discussed)
* Junit (already discussed)
* Tomcat.  Please read the issues I encountered in the embedded wiki.  I got a lot of shit from the Seam division for how I did the Tomcat integration.  Some of it was unavoidable (specifically, the URL Handler junk), others, specifically the JNDI hacks could have been avoided, but the consequence would have been changes throughout the JBoss AS codebase.  Changes I was unwilling to do.  The whole idea of embedded is that we should have to have a whole team dedicated to maintaining it because it would be a thin packaging around the AS distribution.  The less code that's in embedded, the better it is.

* Other app servers.  If done correctly, JBoss AS should be reusable in other application server environments.  We should be able to use the environments TM, JNDI, etc. services.  But I think this should be a LOW PRIORITY.  Given resource constraints, we'd need at least one dedicated person on embedded to be able to make this a reality.

Well, that's all I can think of right now....


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106121#4106121

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4106121