[starksm64]

I believe that the environment that i speak about can be a central piece in binding jBPM with SEAM, Drools and the server environment together.

There are only 2 ways to pass information down the callstack : using method parameters and a thread local. Now, thread local environmental data is scattered throughout specs and framework classes. I believe that this should be centralized.

Each project can define their environment structure. E.g. for jBPM this could look something like this:

businessProcess context
 + processExecution context
 + taskInstance context
 + token context
 + processInstance context
 + command context
 + processDefinition context
 + node
 + transition
 + timer
 + staticVariables
 + userBeans
 + service
 + persistenceService
 + messagingService
 + tasksMgmtService
 +
 + factory
 + persistenceServiceFactory
 + messagingServiceFactory
 + taskMgmtServiceFactory
 +
 + configuration

Ah,... one more thing. In my prototype, i defined each node in the environment tree as a stack. so that it supports nested invocations which cause nested environments being stacked on top of each other.

regards, tom.

This is a variable namespace structure that would be layered onto the repository to provide a means to lookup ${x.y.z} values with the value coming from one or more scopes.

[starksm64]

This bears no resemblence to the Microcontainer metadata repository.

The metadata repository is a mechanism to apply annotations/policy at different levels
(rather than just the class and joinpoint).

I definitely do NOT (edited) want the metadata repository to become what you describe.

Adrian Brock's 5th law programming:
"Do one thing well".

I see this as a usecase where there are MetaDataLoader/MetaDataCombiner implementations that combine the key namespace and repository scope to provide an Nx8 data structure. Its not clear that every key dimension actually has a value so N may be small in practise.

[tom.baeyens]

That was the polite version.
The impolite version moves you to here:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=237

I notice Alex has the same issue with you in the JBossXB forum.
But he hasn't got tired of providing urls to you yet.

adrian, you and alex are right. i don't use the search button enough. i'll work on it.

but for the mc discussions this poses a problem for jbpm-jems integration that i don't know how to solve.

my goal is to integrate jbpm into jems as good as possible. the discussion on mc that i did find, i was mostly unable to follow. one of the things i tried was creating a prototype to understand my needs better and to improve my ability to follow the mc discussions. also i spend some time digging the code. i made some progress, but realized that with the time i have available, i won't be able to participate actively in the discussions. as an alternative, i tried to express my wishlist in the hope you guys pick up the things that you consider good features for the MC.

i still don't get completely the scope and purpose that you target for the mc in relation to the features that i consider important for integrating jbpm, drools, seam and the other appserver components. i'm not saying that i want all those features in the mc. i'm only trying to find out what the scope of the mc is so that i know what is in there and what should be developed on top of it.

i realize i'm not a superstar but i still think that my prototype contains some valuable ideas that could be an improvement on current jems components. it's a variation on the seam contexts. those concepts are what i plan to use in the next generation jbpm to improve embeddability. i believe they could be interesting for other jems components as well, maybe as a layer on top of the mc. since i'm not able to explain these ideas in relation to mc, i can only be available in case anyone is interested to have a look at them.

regards, tom.

[adrian.brock]

Hi Tom,

The purpose of the Microcontainer project is to create an environment to control
the management, configuration and deployment of beans.

Things on top of this like application specific datastructures or mechanisms
(e.g. Seam's "bijection") are not problems for the MC.
If they were, there wouldn't be a Seam project, just an MC project. :-)

I don't have a problem with you trying to prototype your needs and seeing how
they possibly fit into the MC as a generic configuration mechanism.
But it must be generic and not Jbpm or any other project specific.

e.g. JNDI binding is a generic deployment feature and you could even
argue that ENC construction is as well. But constructing an ENC from
EJB3 specific metadata is not a problem for the MC.
For this to go into the MC project, it would need to be a generic ENC
construction mechansim that EJB3 targets.

Like I said, I don't really have time to look at prototypes anyway.
I much prefer to understand features individually and the reasons
why these exist rather just being constructed from simpler primitives.

Regards,
Adrian

[adrian.brock]

I see this as a usecase where there are MetaDataLoader/MetaDataCombiner implementations that combine the key namespace and repository scope to provide an Nx8 data structure. Its not clear that every key dimension actually has a value so N may be small in practise.

I don't think I follow this.
I specifically want to differentiate metadata that can be persisted and distributed
across servers, i.e. typesafe policy declarations
from metadata attachments that is just runtime context and not even necessarily typed.

An example of the first is a user/password to access a database (configuration data).
An example of the second is a user/password that just logged into the application (runtime data).

[starksm64]

I don't think I follow this.
I specifically want to differentiate metadata that can be persisted and distributed across servers, i.e. typesafe policy declarations
from metadata attachments that is just runtime context and not even necessarily typed.

An example of the first is a user/password to access a database (configuration data). An example of the second is a user/password that just logged into the application (runtime data).

Yes, but I don't see that this distinction precludes integration of data into the repository. Metdata that can be persisted and distributed across servers is data that has a policy associated with a profile service that allows for this. Data that is populated via application/server level aspects without a policy still should be able to leverage the metadata repository.