Breaking MC in 2?

[starksm64]

From Tom,

last two months i have been abstracting jbpm from the environment in which it runs. here i want to share and challenge the observations i made during that work. the conclusion i will make is that we don't have a separate dependency injection (di) container.

in 3.0, jbpm's main dependency is a hibernate session. the occasion to expand this was the introduction of a new dependency on a async message system. that made me realize that jbpm needs a number of services from its environment. each of those services must be pluggable so that jbpm can be embedded in any environment (junit with mock svcs, j2se, j2ee, spring, ...). the work i did to accomodate this is interesting. i found myself developing patterns as in jboss and spring but dedicated to my use case so less general and less complex.

i believe that a simple library can be written to support the same abstraction in a general way. meaning no service implementations. just a framework that bridges between a component and the services that are used from the environment.

ok... so that is exactly what spring does. right ?

i think that our new microcontainer has a different goal and target. since the focus has been to implement a service container itself. so mc ties 2 things together that i would like to see more separated: 1) classloading, deployment & service container (== all you need to boot a server) and 2) aop, thread local contexts(as in SEAM), service usage (== all you need to write a component).

is a clear separation between these 2 thinkable in the mc ?

another issue that kept me from using the mc were the library dependencies. i believe it is possible to write a decent service provider framework (or di-container) in less then 200 K based on only J2SE 1.4.

also i think that a separate service provider framework is a necessary key element for what i would call "an integrated development environment" :) meaning one environment in which you write your domain model, your services and your web service integration. i believe this is one of the meanings of "SOA" :-)

thoughts ?

regards, tom.
[e-mail]

[adrian.brock]

From me:

There are already tasks to reduce the dependencies,
e.g. splitup jboss-commons, remove the requirement to use xerces
from JBossXB, etc.

The MC is already "200K" with no attempt by me to trim it,
e.g. it still contains the prototypical classloader and notification
implementation which belong as plugins.

The problem is commons and xerces.

adrian@dev22:~/jboss-head/workspace/kernel/output/microcontainer-1.0.1/lib> ls -lh
total 2.6M
-rw-r--r-- 1 adrian adrian 167K 2005-12-06 12:35 concurrent.jar
-rw-r--r-- 1 adrian adrian 798K 2005-12-06 12:35 jboss-common.jar
-rw-r--r-- 1 adrian adrian 59K 2005-12-06 12:35 jboss-container.jar
-rw-r--r-- 1 adrian adrian 20K 2005-12-06 12:35 jboss-dependency.jar
-rw-r--r-- 1 adrian adrian 207K 2005-12-06 12:35
jboss-microcontainer.jar
-rw-r--r-- 1 adrian adrian 2.6K 2005-12-06 12:35 namespace.jar
-rw-r--r-- 1 adrian adrian 1.2M 2005-12-06 12:35 xercesImpl.jar
-rw-r--r-- 1 adrian adrian 190K 2005-12-06 12:35 xml-apis.jar

[rmaucher]

Maybe you could make a Java 5 version with no dependencies.

[adrian.brock]

Certainly we could drop concurrent.jar
by making this class more configurable (i.e. use the Java5 util classes)

http://anoncvs.forge.jboss.com/viewrep/~raw,r=1.4/JBoss/jboss-common/src/main/org/jboss/util/CollectionsFactory.java

[adrian.brock]

Maybe you could make a Java 5 version with no dependencies.

One of the dependencies is JBossXB's schema processing is on internal xerces schema api.
This is an old version that is broken in com.sun.org.apache.xerces.*

[tom.baeyens]

but my main question remains:

does anyone else see the need for splitting the functionality of the mc into 2 parts:

1) all you need to run a server (classloading, deployment & service container)

2) all you need to write a component that makes use of services from the environment (aop, thread local contexts(as in SEAM), service usage). all of this so that users can write a component against the intermediate framework and later deploy it to different environments. i believe that to some extend, aop and thread local contexts can and should be opened up to the developer as a way to do this.

basically i was just pinging to see if i was freeweeling or if others had similar ideas...

size and java version are irrelavant imo.

regards, tom.

[adrian.brock]

but my main question remains:

does anyone else see the need for splitting the functionality of the mc into 2 parts:

1) all you need to run a server (classloading, deployment & service container)

2) all you need to write a component that makes use of services from the environment (aop, thread local contexts(as in SEAM), service usage). all of this so that users can write a component against the intermediate framework and later deploy it to different environments. i believe that to some extend, aop and thread local contexts can and should be opened up to the developer as a way to do this.

basically i was just pinging to see if i was freeweeling or if others had similar ideas...

size and java version are irrelavant imo.

regards, tom.

But, there already is that dichotomy.

In fact it is not a dichotomy, there are multiple levels
and in many cases they are more orthogonal than levels :-)

"Plain" dependency state machine (the MC)
* With Bean XML deployment
* With AOP
* With Custom classloading
* With metadata repository
* With decorators (kernel aspects)
* With JBoss services + decorators (transaction manager, datasource, jndi, etc.)
* With thirdparty services (integration layer/abstraction)
* With additional component architecture (EJB3, Seam, etc.)
* With JBoss deployers/profile service
* With integration of old JMX Microkernel into one dependency space
etc.

[adrian.brock]

The fundamental idea is that you just write a POJO that
"DOES ONE THING WELL" (Can we trademark that phrase? :-)

[adrian.brock]

"i believe that to some extend, aop and thread local contexts can and should be opened up to the developer as a way to do this."

If I understand your question, I think that is a question for the AOP/EJB3/Seam projects?

The MC is responsible for the deployment/configuration behaviour
and only jumps into runtime behaviour by allowing decorators/aspects/interceptors
from the deployed services. e.g. transaction demarcation, security, monitoring, etc.

It does define or implement those services, it just "deploys" them.