External Contribution to AS Embedded

[alrubinger]

With the jboss-bootstrap:2.0.0 series now integrated into Branch_5_x, we can start to entertain external contributions as we've got greater focus. I had some conversations over email with Josh Davis, who raised on the dev-list:

http://lists.jboss.org/pipermail/jboss-development/2009-June/014609.html

"Josh Davis" wrote:
I'm game for doing some development, or at least seeing if I can deploy my app and run unit tests with a snapshot build and report problems. I've checked out http://anonsvn.jboss.org/repos/jbossas/projects/embedded/trunk, but I think I need some help getting it to build. I'm not sure which Maven repository I'm supposed to use to get it to build. I'm guessing the instructions for the JBoss AS project don't apply?

You're coming in at a great time, though it might be a bit early if your goals are just to "get things working" for you. The first prototype of the new Embedded stuff I'd committed sometime last week, and it's the most ugly code I've ever put into svn.

Your SVN location is correct, however, we still need to massage this all into some working form. The general idea is:

* Bring in all of the AS Dependencies
* Start up AS by using the bootstrap APIs, and point it at a JBOSS_HOME installed somewhere on your system
* Watch everything break

This is because AS itself still makes a series of assumptions about the runtime environment, and I've been addressing these one-by-one. Not necessarily a wonderful place for a newbie to start (==frustrating AS legacy stuff).

A great place for you to begin would actually be from within the Bootstrap project:

https://jira.jboss.org/jira/browse/JBBOOT
http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/

This is the component responsible for obtaining all AS configuration, starting up Microcontainer, pointing it to the root bootstrap XML, and running. It's the thing that AS Main now calls to startup everything.

Would recommend you have a look at some of the open issues in JBBOOT JIRA. The whole project should be fully JavaDoc'd and tested; the unit tests for each projects are meant to be self-documenting as well. You can learn how to setup/start the server, fire lifecycle events, etc.

Real Embedded work that you may dive into is about 1-2 weeks away from now, I'd say. If you wanna dig into Bootstrap (which is a prereq for learning AS startup anyway), try for patches on some of the easier issues.

As to the Maven repo:

http://www.jboss.org/community/wiki/MavenSettings

It's the same repo as all of JBoss; http://repository.jboss.org/maven2.

These settings upon a fresh checkout of jboss-bootstrap should get you on your way.

S,
ALR

[alrubinger]

"Josh Davis" wrote:
I'll take a look at the bootstrap stuff. It makes sense having an API/SPI for starting up the MC, then it starts everything else.

I'll check out the bootstrap stuff and read through some JIRAs. I'll probably need help in seeing which ones are 'easy'.

Let's start with making a nice test:

https://jira.jboss.org/jira/browse/JBBOOT-56

Easy and uninteresting is:

https://jira.jboss.org/jira/browse/JBBOOT-86
https://jira.jboss.org/jira/browse/JBBOOT-89

...though they'll get you making patches etc and into the dev process.

S,
ALR

[alrubinger]

"Josh Davis" wrote:
Good stuff. I'll take a look at that tomorrow. Gotta do some real work today (with beta3).

Yep. A good alternative to a full Embedded AS is using the MCServer (jboss-bootstrap-impl-mc) to point to some Microcontainer bootstrap.xml (==*jboss-beans.xml) and fire up POJO deployments for testing. It's a dead simple way of creating your own runtime based on MC.

S,
ALR

[alrubinger]

"Josh Davis" wrote:
I tried my hand at making the test for https://jira.jboss.org/jira/browse/JBBOOT-56

Check the patch attached to the issue and let me know if that's what you meant.

Great code in general. I appreciated your commitment to documentation and cleanup/centralization as you go along.

In ripping jboss-bootstrap out of the Application Server, I've been especially sensitive to violation of scope and extending a component's concerns outside its domain. In this case, startup/shutdown of bootstraps is provided by impl-base, and the attached patch addresses test cases in impl-mc. This makes it more of a compliance/acceptance test where impl-mc validates it's getting a good impl-base.

So I've attached an alternate way of tackling the issue in "JBBOOT-56.v2.ALR.patch" on the JIRA. Have a look and let me know what you think.

Some misc minor notes:

* You don't need AtomicInteger in LifecycleOrderPojo (as you hint); this is all single-threaded.
* We need to get you set up w/ JBoss licence headers and preferably with a formatter (if you're in Eclipse I have code templates).

I'm impressed that you've picked up the Bootstrap Server API and MC jboss-beans.xml deployments so quickly. This was a good, working patch you've provided. So let's just address the scope issue and move forward on something else? ;)

Outstanding questions:

* Do you have an account on jboss.org? This enables posting to the forums, JIRA assignments, etc.
* Have you yet signed a contributor's agreement? Once done I can commit on your behalf, and after a few patches, get you commit access.

http://jboss.org/contributor

S,
ALR

[jaikiran]

"ALRubinger" wrote:

* Do you have an account on jboss.org? This enables posting to the forums, JIRA assignments, etc.

Yep, he has :) http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156987

[pgmjsd]

"ALRubinger" wrote:

Great code in general. I appreciated your commitment to documentation and cleanup/centralization as you go along.

In ripping jboss-bootstrap out of the Application Server, I've been especially sensitive to violation of scope and extending a component's concerns outside its domain. In this case, startup/shutdown of bootstraps is provided by impl-base, and the attached patch addresses test cases in impl-mc. This makes it more of a compliance/acceptance test where impl-mc validates it's getting a good impl-base.

I wasn't sure what each module was for. I just looked for a test that started up 'bootstraps' inside a 'server'. Got it... impl-mc is for the MC specific stuff like parsing XML and whatnot, impl-base is for basic lifecycle sequence.

"ALRubinger" wrote:

So I've attached an alternate way of tackling the issue in "JBBOOT-56.v2.ALR.patch" on the JIRA. Have a look and let me know what you think.

Downloaded the patch, here's what I think:
* I had to move the files in the patch because the patch was based on a subdirectory. I'll have to see if IDEA can make patches with a directory different from the base of the project. I'm using boostrap/trunk as the base.
* Now I understand what 'a Bootstrap' is, sort of. Partial understanding of the module structure.
* I'm not sure about the "package per jira issue" convention. But hey... if that's how you wanna roll.

"ALRubinger" wrote:

Some misc minor notes:

* You don't need AtomicInteger in LifecycleOrderPojo (as you hint); this is all single-threaded.
* We need to get you set up w/ JBoss licence headers and preferably with a formatter (if you're in Eclipse I have code templates).

Okay. Wasn't sure about AtomicInteger. I have multi-threading on the brain.

I have eclipse, but I prefer IDEA. I've already made templates for the license and such for IDEA.

"ALRubinger" wrote:

I'm impressed that you've picked up the Bootstrap Server API and MC jboss-beans.xml deployments so quickly. This was a good, working patch you've provided. So let's just address the scope issue and move forward on something else? ;)

Yes, now that I understand everything (yeah, right). ;)

"ALRubinger" wrote:

Outstanding questions:

* Do you have an account on jboss.org? This enables posting to the forums, JIRA assignments, etc.
* Have you yet signed a contributor's agreement? Once done I can commit on your behalf, and after a few patches, get you commit access.

http://jboss.org/contributor

I'm forum/wiki/JIRA enabled. But I haven't signed a contributor agreement in a while. I pre-date the shiny new contributor sign up web application. ;)

[alrubinger]

"pgmjsd" wrote:
I wasn't sure what each module was for. I just looked for a test that started up 'bootstraps' inside a 'server'. Got it... impl-mc is for the MC specific stuff like parsing XML and whatnot, impl-base is for basic lifecycle sequence.

The Wiki documentation I'll be posting this week will very clearly delineate the purpose of each project, but yeah, that's about it. spi/impl-base defines a "Server" as "just some thing that has a simple lifecycle". spi-mc extends this to tie into the Microcontainer Kernel/Controller. And spi-as brings in all the AS-specific constructs/configuration. The goal is for many AS subprojects to use spi-mc directly to create their own slim/custom runtimes for testing, and then these may be consumed entirely by AS later.

"pgmjsd" wrote:
Downloaded the patch, here's what I think:
* I had to move the files in the patch because the patch was based on a subdirectory. I'll have to see if IDEA can make patches with a directory different from the base of the project. I'm using boostrap/trunk as the base.

patchBaseDir$>patch -p0 < /location/to/patch

...assuming you're on *nix. But in the future I'll base off "trunk", N/P.

"pgmjsd" wrote:
* Now I understand what 'a Bootstrap' is, sort of. Partial understanding of the module structure.

Again, Wikis this week will take out a lot of the guesswork.

"pgmjsd" wrote:
* I'm not sure about the "package per jira issue" convention. But hey... if that's how you wanna roll.

This is something we'd adopted with some success in EJB3. Basically the JIRA-issue namespace allows us to be very clear about which classes are used in which tests. For shared/common stuff, the ".jbbootXX" package isn't necessary, but in some cases its convenient to show the isolation. I'm not going to enforce any hard-and-fast rules here. So long as everything is tested in readable/obvious form, do what makes most sense to you.

"pgmjsd" wrote:
I have eclipse, but I prefer IDEA. I've already made templates for the license and such for IDEA.

Great. Whatever IDE you prefer is your choice; I'm just best equipped to help you out on Eclipse.

"pgmjsd" wrote:
I'm forum/wiki/JIRA enabled. But I haven't signed a contributor agreement in a while. I pre-date the shiny new contributor sign up web application. ;)

Let's get you logged into the new webapp; it'll make the .org team proud. :) Then I can expedite your application.

S,
ALR

[wolfc]

"ALRubinger" wrote:

"pgmjsd" wrote:
* I'm not sure about the "package per jira issue" convention. But hey... if that's how you wanna roll.

This is something we'd adopted with some success in EJB3. Basically the JIRA-issue namespace allows us to be very clear about which classes are used in which tests. For shared/common stuff, the ".jbbootXX" package isn't necessary, but in some cases its convenient to show the isolation. I'm not going to enforce any hard-and-fast rules here. So long as everything is tested in readable/obvious form, do what makes most sense to you.

The rules which apply and should be enforced are:
1. each test must clear state which function it's testing
We have a lot of tests which do some form of setup do get to the actual state in which a function can be tested. If a test doesn't clearly define its goal, then regression might happen because an unrelated function (which is used) is refactored.
2. each test is a guard against (backwards compatibility) regression
You not change a test because it's failing. That would break backwards compatibility by default. You should only change those bits of a test that are affected by a bug fix.

The two are very much intertwined, but as a rule the Jira issue stipulates the test goal and keeps track of which version is affected.

[alrubinger]

I've added the start of some documentation for the Bootstrap project. Please let me know if anything is unclear or overly incomplete.

http://www.jboss.org/community/wiki/JBossBootstrap

S,
ALR

[johnbailey]

Has there been any updates to this issue? It looks like a patch was submitted but never applied. Just looking through the open JBBOOT issues and trying to resolve as many as I can.