10:14 a.m.
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(a)redhat.com>
To: "JBoss.org development list" <jboss-development(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
2:04 a.m.
New subject: AS Embedded and The Full AS Dependency Set
It will, but I also hope we won't just provide a *full AS dep list* pom
- we should have one per spec/functional area (i.e. jpa/hibernate, jca,
servlet, ..) and they most likely
would be in a -client and -impl to be real good for good isolation.
Hopefully this one pom will be built by referencing sub-poms ? or am i
dreaming ?
/max
Robb Greathouse wrote:
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(a)redhat.com>
To: "JBoss.org development list"<jboss-development(a)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
1:34 p.m.
New subject: AS Embedded and The Full AS Dependency Set
Good points, I'll clarify.
"AS Embedded" depends upon Application Server, hence the full AS
Dependency Set. It's powered by "JBoss Bootstrap", which has an MC
implementation without any AS constructs. AS Embedded is *only* a
launcher, and is analogous to AS Main.
It's the modularization efforts which will eventually get us a more
fine-grained set of dependencies; these may later be used to define the
"JPA/Hibernate Profile". The combination of modularized dependencies
and an appropriate bootstrap definition is known as "JBoss Reloaded",
currently in a prototyping phase by Carlo for EJB3 Embeddable.
So Max, yes, I'd expect the "one POM to rule them all" for AS to simply
declare a series of transitive dependencies, and it becomes the
authority over exactly what comprises AS.
Robb, yes, TDD is one major goal of Embedded. But it goes deeper. When
each subproject defines its own bootstrap, it immediately becomes
eligible for use in standalone environments, and may be re-composed into
larger units. For instance the new JCA implementation will be used
standalone, we'll consume it for EJB3 Embeddable, and it'll go into AS.
S,
ALR
On 06/14/2009 03:04 AM, Max Rydahl Andersen wrote:
It will, but I also hope we won't just provide a *full AS dep
list* pom
- we should have one per spec/functional area (i.e. jpa/hibernate, jca,
servlet, ..) and they most likely
would be in a -client and -impl to be real good for good isolation.
Hopefully this one pom will be built by referencing sub-poms ? or am i
dreaming ?
/max
Robb Greathouse wrote:
> 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(a)redhat.com>
> To: "JBoss.org development list"<jboss-development(a)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
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
5953
days inactive
5955
days old
jboss-development@lists.jboss.org
2 comments
3 participants
participants (3)
-
Andrew Lee Rubinger -
Max Rydahl Andersen -
Robb Greathouse