Proper definition of embedded jboss

[starksm64]

So after fumbling around with a proper definition of what embedded jboss is, its clear we need to define it in terms of api, configuration, and integration plugins, artifacts. We also need to get the current embedded subproject refactored. What the the usecases for which there need to be unit tests in the server codebase?

[bill.burke]

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....

[wolfc]

Embedded must have it's own codebase. It should not reside in AS trunk. This will allow it to have an independent release/life cycles.

Thus it won't be released with active snapshots (1), we can continue development post AS release (2) and it won't fall on it's ass when major refactoring takes place (3).

1: See JBoss Embedded Beta2 release
2: See Embedded EJB 3 RCs
3: See Embedded EJB 3 RC 9

It should then become apparent what it takes for AS to be a component in a consuming product. (and thus defining the EAP roadmap)

As for what tests should be in AS codebase: all the SPI requirements put down by Bill (under Refactoring) must be tested before AS is delivered.

[julien1]

Bill,

if you want to be useful (for the JBoss Portal project), you should provide us something similar to dysoweb http://dysoweb.requea.com/ based on JBoss MC.

[bill.burke]

Bill,

if you want to be useful (for the JBoss Portal project), you should provide us something similar to dysoweb http://dysoweb.requea.com/ based on JBoss MC.

IMO, this is not the scope of Embedded. Embedded is supposed to work in the environment that instantiates it.

[julien1]

I see what you mean the sentence "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. " confused me. I assumed it would work cross deployments.

Bill,

if you want to be useful (for the JBoss Portal project), you should provide us something similar to dysoweb http://dysoweb.requea.com/ based on JBoss MC.

IMO, this is not the scope of Embedded. Embedded is supposed to work in the environment that instantiates it.

[newtonm]

Hi Bill, Scott,

Having looked at the Embedded JBoss documentation in the wiki and from my current work on the JBoss Microcontainer User Guide I think that we could benefit from a change in name for the project.

Given that Embedded JBoss is all about using JBoss enterprise services and our EJB3 container in different runtime environments (by allowing them to be loaded by different classloaders) how about:

JBoss Reloaded

This carries on the tradition of naming releases after the Matrix and hints at the fact that you are 'reloading' JBoss services through different classloaders. In addition it starts with the prefix 'JBoss' and does not lend itself to being used as a noun which is helpful since Embedded JBoss is really a way of packaging up the microcontainer with some integration code so that it can be used in other runtimes. In this sense it isn't a product as such.

The JBoss Reloaded project would therefore contain distributions and docs to explain how to configure JBoss services and the EJB3 container in Tomcat, GlassFish, standalone Java SE apps, etc...

I already have a part in the JBoss Microcontainer User Guide called 'Integration' where I intend to explain how the microcontainer is used within JBoss AS. We could also add in here explanations of how to use it in Tomcat and GlassFish if necessary.

I ultimately would like to develop a single story with which to explain our technology all the way from JBoss Microcontainer through to JBoss AS. Seen in this light the JBoss Reloaded project would sit nicely in the middle, demonstrating uses of our technology that gradually become more and more integrated with different runtimes until we arrive at JBoss AS 5 which is the best of the bunch :)

what do you think?

Mark Newton

[starksm64]

I don't so much care about the name as the breaking out of the project with required integration code and docs. That makes sense.

[maxandersen]

We are depending rather heavily on the embedded jboss in context of Seam and being able to run tests from a plain unittest so i'm very interested in this discussion and I can provide you with the perfect environment to test it in: JBoss Tools

In here we simply just run the testng seam unit test with the basic classpath and everything seems to work fine with it (except for the outstanding issue with MC about failing when having manifest.mf and ejb-jar.xml in exploded dir).

[starksm64]

Point us to a page that describes how to set this up and run this.

[maxandersen]

How to install JBoss Tools (nightly builds are best until we GA):
http://wiki.jboss.org/wiki/Wiki.jsp?page=InstallingJBossToolsNightlyBuilds

How to use TestNG setup in jboss tools (requires to install the testng plugin from testng.org):
http://download.jboss.org/jbosstools/nightly-docs/seam/en/html_single/index.html#testNG

[starksm64]

Ok, I'll have to try this on my laptop as I have not been able to get eclipse 3.3.x to run on my rhel4 server.

[maxandersen]

hmm - weird.

what happens with eclipse 3.3 on rhel 4?

[starksm64]

Some swt library problem:

[starksm@succubus forums]$ ~/java/eclipse-europa/eclipse
!SESSION 2007-11-28 15:33:18.219 -----------------------------------------------eclipse.buildId=I20070625-1500
java.version=1.5.0_11
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
Framework arguments: org.eclipse.platform
Command-line arguments: -os linux -ws gtk -arch x86 -consoleLog org.eclipse.platform

!ENTRY org.eclipse.osgi 4 0 2007-11-28 15:33:19.132
!MESSAGE Application error
!STACK 1
java.lang.UnsatisfiedLinkError: no swt-gtk-3346 or swt-gtk in swt.library.path, java.library.path or the jar file
 at org.eclipse.swt.internal.Library.loadLibrary(Library.java:219)
 at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151)
 at org.eclipse.swt.internal.C.<clinit>(C.java:21)
 at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63)
 at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54)
 at org.eclipse.swt.widgets.Display.<clinit>(Display.java:128)
 at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:482)
 at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161)
 at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:133)
 at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:86)
 at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363)
 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504)
 at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
 at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
 at org.eclipse.equinox.launcher.Main.main(Main.java:1144)

!ENTRY org.eclipse.osgi 2 0 2007-11-28 15:33:19.258
!MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists:
!SUBENTRY 1 org.eclipse.osgi 2 0 2007-11-28 15:33:19.258
!MESSAGE Bundle update@plugins/org.eclipse.jdt.compiler.apt_1.0.0.v20070510-2000.jar [55] was not resolved.
!SUBENTRY 2 org.eclipse.jdt.compiler.apt 2 0 2007-11-28 15:33:19.258
!MESSAGE Missing imported package org.eclipse.jdt.internal.compiler.tool_0.0.0.
!SUBENTRY 1 org.eclipse.osgi 2 0 2007-11-28 15:33:19.259
!MESSAGE Bundle update@plugins/org.eclipse.jdt.apt.pluggable.core_1.0.0.v20070529-2100.jar [176] was not resolved.
!SUBENTRY 2 org.eclipse.jdt.apt.pluggable.core 2 0 2007-11-28 15:33:19.259
!MESSAGE Missing imported package org.eclipse.jdt.internal.compiler.tool_0.0.0.
!SUBENTRY 2 org.eclipse.jdt.apt.pluggable.core 2 0 2007-11-28 15:33:19.259
!MESSAGE Missing imported package org.eclipse.jdt.internal.compiler.apt.dispatch_0.0.0.
!SUBENTRY 2 org.eclipse.jdt.apt.pluggable.core 2 0 2007-11-28 15:33:19.259
!MESSAGE Missing imported package org.eclipse.jdt.internal.compiler.apt.model_0.0.0.
!SUBENTRY 2 org.eclipse.jdt.apt.pluggable.core 2 0 2007-11-28 15:33:19.260
!MESSAGE Missing imported package org.eclipse.jdt.internal.compiler.apt.util_0.0.0.
!SUBENTRY 1 org.eclipse.osgi 2 0 2007-11-28 15:33:19.260
!MESSAGE Bundle update@plugins/org.eclipse.jdt.compiler.tool_1.0.0.v_771.jar [180] was not resolved.
*** glibc detected *** double free or corruption (!prev): 0x080706e8 ***
Aborted

[maxandersen]

is that on a 64 bit machine ?

then you need Sun Java 2 Standard Edition 5.0 Update 11 for Linux x86_64

anyway I recommend you use a 32bit java anyway so you can use the visual editor which we don't have a 64 bit bundle for yet.