11 Replies Latest reply on Feb 13, 2009 5:17 AM by alesj

    Deployment contextual information

    dmlloyd

      Do deployments have a notion of contextual information? Like, deployment X is associated with context classloader Y or security context Z?

      I'm struggling with this idea in the Threads module. The case I'm thinking of is that say you have two deployments, X and Y. They both use the same thread pool. But they need to have different contextual information - context classloader is just one example; logging context might be another, or security context or even something trivial like a temporary name attached to the thread name or something like that. When each deployment runs a task, that task should be run with the proper contextual information set.

      Is there any provision for accessing deployment contextual information at a MC level?

        • 1. Re: Deployment contextual information
          alesj

          Deployment's MetaData?

          • 2. Re: Deployment contextual information
            alesj

             

            "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

              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

                Scratch the "implements MetaData" part. I didn't read what I thought I read :)

                • 5. Re: Deployment contextual information
                  alesj

                   

                  "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

                    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

                       

                      "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

                        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

                          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

                            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

                              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.