[jboss-dev] AS Embedded and The Full AS Dependency Set

Robb Greathouse robb.greathouse at jboss.com
Fri Jun 12 11:14:44 EDT 2009


Will this enable test driven development to work inside JBoss Developer Studio? 

We talked about this a few months ago and the general agreement was that true TDD would be dependent on having AS Embedded working.

Robb Greathouse
JBoss
CELL   505-480-4639
OFFICE 505-255-2652
FAX    505-554-2834

----- Original Message -----
From: "Andrew Lee Rubinger" <andrew.rubinger at redhat.com>
To: "JBoss.org development list" <jboss-development at lists.jboss.org>
Sent: Friday, June 12, 2009 12:45:28 AM GMT -06:00 Central America
Subject: [jboss-dev] AS Embedded and The Full AS Dependency Set

With Branch_5_x starting off the newer jboss-bootstrap, I've been 
prototyping a bit with an Embedded launcher for AS.  Goals are:

* User defines one dependency upon org.jboss.embedded:someArtifact
* Entire AS dependency set (==all JARs used in the runtime) are brought 
in and are available for use in tests and upon the runtime test classpath

The key here is that the AS dependency set wholly ends up on the 
application ClassLoader.  Later on child>parent delegation takes place 
and the app CL is the defining CL for everything (except webapps or 
other things which define explicit scoping).

What I need is a mechanism to bring in the AS dependency tree in one 
fell swoop.  Most of this is accomplished by:

org.jboss.jbossas:jboss-as-build (All AS modules and *most* 3rdparty deps)

But that doesn't account for everything.  I also need to explicitly 
define, at a minimum:

org.jboss.jbossas:jboss-as-management:jsr77
jboss.web:jsp-api
jboss.web:el-api
...probably more stuff I haven't yet discovered.

I'd be much cleaner if AS itself could provide one POM artifact which 
held all deps.  Then Embedded could bring in this one dependency and get 
everything else transitively.  Embedded versions then become tied to AS 
releases.

Can we add this?  Is there a better way that occurs to anyone?

BTW I've got a series of docs in progress for the Wiki soon, but have 
preferred to do proof-of-concept before posting it.  I'll ping back here 
when there's docs and source to comb through.

* Alternative Boot Method *

There is another way to boot AS, which is to be selective about the 
classes allowed upon the application ClassLoader.  This is the current 
solution taken by AS Main, and the specialized assembly which 
cherry-picks eligible classes is provided by run.jar.

This gives us another Embedded mode which uses a similar assembly on the 
application ClassLoader, and then the rest of the classes are brought in 
via the standard jboss-cl models as we normally do.

The drawback to this approach is that the user is not able to reference 
classes such as the MC Kernel because this imposes invalid parent>child 
ClassLoader delegation resulting in NCDFE.  So it's, at the moment, good 
for little more than starting and shutting down AS.

S,
ALR

-- 
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com

_______________________________________________
jboss-development mailing list
jboss-development at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development



More information about the jboss-development mailing list