-
1. Re: Deployment contextual information
alesj Feb 11, 2009 4:13 PM (in response to dmlloyd)Deployment's MetaData?
-
2. Re: Deployment contextual information
alesj Feb 11, 2009 4:20 PM (in response to dmlloyd)"alesj" wrote:
Deployment's MetaData?
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-structure-spi/src/main/java/org/jboss/deployers/structure/spi/DeploymentUnit.java
See MDR on how MetaData can be used.
e.g. push in temp thread info into Thread ScopeLevel -
3. Re: Deployment contextual information
dmlloyd Feb 11, 2009 5:12 PM (in response to dmlloyd)I see - so I can attach any kind of MetaData, so long as it implements MetaData? Does the MDR (or any other project) define a convention for this?
What is the lifespan of something I put in there? Can I cause leaks by attaching stuff? Is it removed on undeploy somehow? -
4. Re: Deployment contextual information
dmlloyd Feb 11, 2009 5:13 PM (in response to dmlloyd)Scratch the "implements MetaData" part. I didn't read what I thought I read :)
-
5. Re: Deployment contextual information
alesj Feb 12, 2009 4:19 AM (in response to dmlloyd)"david.lloyd@jboss.com" wrote:
I see - so I can attach any kind of MetaData, so long as it implements MetaData? Does the MDR (or any other project) define a convention for this?
Look at MutableMetaData class.
MetaData == any object;
We just have annotation notion for ease of use.
Another useful class is MetaDataStack,
so you can get to MetaData instance from anywhere
- via classic thread local hack. :-)"david.lloyd@jboss.com" wrote:
What is the lifespan of something I put in there?
It's up to you.
We don't have any magic cleaning.
We only do a cleanup at undeploy - see your last question."david.lloyd@jboss.com" wrote:
Can I cause leaks by attaching stuff?
Sure.
At the end, metadata is nothing more then sophisticated Map.
It's the api that makes it useful."david.lloyd@jboss.com" wrote:
Is it removed on undeploy somehow?
Yes.
In DeployersImpl we call DeploymentContext::cleanup,
which cleans up the scope matching metadata retrievals. -
6. Re: Deployment contextual information
dmlloyd Feb 12, 2009 2:16 PM (in response to dmlloyd)I guess, on further thought, the only sensible policy would be to replicate the context of the caller, so that executor tasks uses the same context classloader, access control context, logging context etc. of the calling thread.
That solves executors anyway. Next I just need to figure out how to make sure that bean methods are also called with the proper context (classloader stuff is probably already figured out, but what about logging and access control context, or future stuff we may think up? is there some AOP magic that does this already? etc)... -
7. Re: Deployment contextual information
alesj Feb 12, 2009 4:51 PM (in response to dmlloyd)"david.lloyd@jboss.com" wrote:
but what about logging and access control context, or future stuff we may think up?
AbstractKernelControllerContext holds creator's AccessControlContext.
I don't understand what you mean with logging. -
8. Re: Deployment contextual information
dmlloyd Feb 12, 2009 5:14 PM (in response to dmlloyd)One of the requirements for the logging pojo service is to allow for separate handling for stdout/stderr (and by extension, other logging categories as well) on a per-deployment basis. Log4j and Logback, the two dominant non-JDK logging frameworks, do this with the notion of a "logging context" which allows the user to swap logging configuration at runtime.
To support this, the proper logging context has to be selected whenever a deployment's classes are initialized or any code from a deployment is executed. -
9. Re: Deployment contextual information
alesj Feb 12, 2009 5:28 PM (in response to dmlloyd)We do this already?
Probably not or I'm missing something.
Where do you put this logging context then?
I guess if you run your services inside some container;
e.g. EJB3 container or MC's ControllerContext,
this could 'carry' this context for you? -
10. Re: Deployment contextual information
dmlloyd Feb 12, 2009 5:38 PM (in response to dmlloyd)We don't do it yet. I'm supposed to be working on it. :-)
My thought was to keep it in a ThreadLocal and swap it in whenever a task is run on behalf of a deployment unit. Which is easy to say...
Alternatively if there was already a way, from any given thread, to discover what DeploymentUnit is being executed, that could work too (the logging context could be stashed on the DeploymentUnit instance). Does the ControllerContext maintain this information? That would actually be generally cool, if so... the Threads module could hook into that to make sure that that information carries over into executed tasks. -
11. Re: Deployment contextual information
alesj Feb 13, 2009 5:17 AM (in response to dmlloyd)I guess this is turning more into dev discussion.
Move this to our dev forum and link this existing discussion.
WRT:"dml" wrote:
Does the ControllerContext maintain this information?
It's the other way around.
DeploymentContext (which is impl detail of DeploymentUnit) holds the info of its CCs.