-
1. Re: scoped repository
"tom.baeyens@jboss.com" wrote:
What i didn't get from the prototype discusssion was wether a the scopes in the repository was a flat list or hierarchical. I think that a hierarchy of scoped/contexts has more potential.
It is heirarchical."tom.baeyens@jboss.com" wrote:
but i also would like to see
* a plain hashmap based context
* a context that refers to process variables
* a context that refers to http request attributes
* a context that refers to http session attributes
* ...
does this make sense ?
Not as new scopes/levels. These are variable namespaces in scopes that already exist in the repository. -
2. Re: scoped repository
Not as new scopes/levels. These are variable namespaces in scopes that already exist in the repository.
can you expand a bit ?
Am i able to plug in my own scope/context in the hierarchical repository that e.g. refers to the process variables. Then i would like to be able to use an expression like:repository.resolve("${businessProcess.variables.myVariable.myProperty}");
One more question. Is the repository envisioned as being thread local, so that it can combine static stuff like the typical JNDI things and threadlocal information like e.g. the security, transaction and business process context ?
thanks.
regards, tom. -
3. Re: scoped repository
"tom.baeyens@jboss.com" wrote:
can you expand a bit ?
Am i able to plug in my own scope/context in the hierarchical repository that e.g. refers to the process variables. Then i would like to be able to use an expression like:repository.resolve("${businessProcess.variables.myVariable.myProperty}");
So we have a disconnect on the use of the term hierarchy. You are talking about object graphs, I am not. Scopes/levels in the hierarchy are not extensible. They have to be deterministically ordered such that selection of the correct scope given a starting scope is easy. There is not a variable resolver notion in the repository. That is an aspect on top of the data. Given your expression, I think you are talking more along the lines of a path expression in the repository, but you have a mixture of scope with object hiearchy. Defining a uniform namespace that can be used consistently across all usecases is something that needs to be defined and is coming up in several projects."tom.baeyens@jboss.com" wrote:
One more question. Is the repository envisioned as being thread local, so that it can combine static stuff like the typical JNDI things and threadlocal information like e.g. the security, transaction and business process context ?
This is the hiearchy I am talking about:org.jboss.repository.spi public interface CommonNames { public int DOMAIN_LEVEL = 0; public int CLUSTER_LEVEL = 1; public int SERVER_LEVEL = 2; public int APPLICATION_LEVEL = 3; public int DEPLOYMENT_LEVEL = 4; public int SESSION_LEVEL = 5; public int THREAD_LEVEL = 6; public int REQUEST_LEVEL = 7; public int N_LEVELS = 8; public static final String REQUEST = "REQUEST"; public static final String THREAD = "THREAD"; public static final String SESSION = "SESSION"; public static final String DEPLOYMENT = "DEPLOYMENT"; public static final String APPLICATION = "APPLICATION"; public static final String SERVER = "SERVER"; public static final String CLUSTER = "CLUSTER"; public static final String DOMAIN = "DOMAIN"; public static final String[] LEVELS = { DOMAIN, CLUSTER, SERVER, APPLICATION, DEPLOYMENT, SESSION, THREAD, REQUEST }; }
Looking up a value in the repository starts with the deepest scope. Consider looking up a user.home value. This would start with the request context, then thread local, then session, deployment context, application context, server, cluster, and finally domain.
Where your previous variable namespace question comes into play is at a scope like SERVER_LEVEL. Here I potentially have multiple sources of user.home data. JNDI is one server level source, system properties are another. You seem to want to treat these as different scopes, I want to threat them as different namespaces. In the absense of an explicit namespace (jndi:user.home, sysprop:user.home) the resolution of user.home is a funtion of the MetaDataLoader.
There is the possibility to combine the lookup value from several scopes/namespaces by plugging in a MetaDataCombiner.
The details are up in the air and we need to define what is easiest to use and manage. -
4. Re: scoped repository
There is not a variable resolver notion in the repository. That is an aspect on top of the data.
this i don't understand yet.
I see 2 distinct, separate use cases for a repository:
1) component container in the server
2) the thread-local environment that is being managed by aspects
while there are many common components that they need, imho, these are different beasts.
What i would like to see for 2) is that a new, thread-local, root repository is created that represents the environment. whenever a thread starts running in jboss for a request. then (typically) aspects will populate the environment repository. the environment repository should accomodate both static and thread local data.
the environment repository should be a superset of JNDI (but with simpler interface). JNDI manages mostly static environmental data. But the environment repository should be the central place where aspects publish their thread-local (=contexts) data. e.g. information like in the EJBContext, JbpmContext, security and transaction context, ...
Imho, the environmental repository should have a tree structure. The default environmental tree node should be based on a plain map, where you can put and get objects. Then there are a set of leaf environment node-types. E.g. one based on meta-data (bean wiring information) that supports lazy initialization of the actual objects. Another leaf-node could be a JbpmTaskInstanceVariablesContext, that knows how to fetch variables from a jbpm task instance.
As you also mention, there should be a hierarchy. In the prototype that i worked out, i used an ordering in each node of the tree. Each node defines the search order for its children. Also the search order is not fixed, but it can be manipulated at runtime. E.g. suppose that jBPM calls a piece of user code, then jBPM decides which parts of the environment tree will be searched for first. Suppose the user code searches for the "adminEmailAddress" key. then we first have to look in the specific process instance, if an adminEmailAddress is not specified there, we look into the process definition, if not their either we look into the jbpm overall configuration, ... until we end up with the jboss server scope. The search algorithm that i written first searches for a given key that is closest to a given node in the environment tree. Closest meaning that first the children are searched for, then upwards, one level at a time.
my current feeling is that the microcontainer is primarily designed to be base for the server and that some of the thread-local environment features ripple through. maybe we should do 2 separate excercises (one for the server-kernel and one for the thread-local-environment) separately and see which components they share in common.
please let me know if you think i'm way off base and waisting our time.
regards, tom. -
5. Re: scoped repository
My experiments can be found in the jbpm repo:
server: cvs.forge.jboss.com
cvsroot: /cvsroot/jbpm
module: lightning
places to start is the doc/???.ppt and the environment test case. -
6. Re: scoped repository
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. -
7. Re: scoped repository
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". -
8. Re: scoped repository
"adrian@jboss.org" wrote:
This bears no resemblence to the Microcontainer metadata repository.
I definitely do want the metadata repository to become what you describe.
These two statements look contradictory... Unless you mean that you are still very far from your goal :-)"adrian@jboss.org" wrote:
The metadata repository is a mechanism to apply annotations/policy at different levels
(rather than just the class and joinpoint).
if this was intended for me to understand, please, reformulate in the mere-mortals-english-language :-)"adrian@jboss.org" wrote:
Adrian Brock's 5th law programming:
"Do one thing well".
I agree... but the question quickly turns into *which* one thing we should all be doing. As long as there are no fines for violating these laws, i'm ok with it.
here's my only law: "If it's green, it works"
regards, tom. -
-
10. Re: scoped repository
"tom.baeyens@jboss.com" wrote:
"adrian@jboss.org" wrote:
This bears no resemblence to the Microcontainer metadata repository.
I definitely do want the metadata repository to become what you describe.
These two statements look contradictory... Unless you mean that you are still very far from your goal :-)
There is a missing NOT."adrian@jboss.org" wrote:
The metadata repository is a mechanism to apply annotations/policy at different levels
(rather than just the class and joinpoint).
if this was intended for me to understand, please, reformulate in the mere-mortals-english-language :-)
Tom. If you want the long discussion use search. There have been
at least 5 such discussions this year, including one from yesterday in the AOP forum.
Adrian Brock's Zeroth law of forums:
I am not a search engine.
If you can't be bothered following the discussions, use search.
Don't expect others to do your homework or provide management summaries
because you are lazy. -
11. Re: scoped repository
And I already told you earlier this week that application specific stuff is not going in the MC.
-
12. Re: scoped repository
"julien@jboss.com" wrote:
If it's green, it works
correction : if it' tested, it works
My version is
"If it is NOT tested it doesn't work or even exist". -
13. Re: scoped repository
"adrian@jboss.org" wrote:
Adrian Brock's Zeroth law of forums:
I am not a search engine.
If you can't be bothered following the discussions, use search.
Don't expect others to do your homework or provide management summaries
because you are lazy.
Adrian, if you can't handle my posts please ignore them. If you can't resist educting me, try being more polite. Then your efforts will have much more success.
regards, tom. -
14. Re: scoped repository
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.