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

[Carlo de Wolf]

Andrew Lee Rubinger wrote:
> 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
This is because jboss.web:jbossweb doesn't define any dependencies.
> ...probably more stuff I haven't yet discovered.
I know JBossTS doesn't have a proper pom as well. See 
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/jta-profile/pom.xml?view=markup 
.
>
> 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?
I think it's more related to having proper poms for sub-projects.
Let's go on a case-by-case. If necessary we can always define virtual 
projects which do have a proper pom, tying the artifacts together.

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