Because I found the method named bindThread() is invoked multiple times at class named StandardContext in Tomcat 7 source code, especially in the method named startInternal(). I do not understand why need to call this method multiple times.
Actually the bindThread() is set the thread context classloader, but I don't konw why still use bindThread() and unbindThread() method pair in the startInternal() invoke multiple times.
Web application start and stop normally happens with the container class loader in effect. Some parts of the start (and stop) process (e.g. firing the application listeners) needs to take place with the web application class loader in effect. bindThread() and unbindThread() are the methods that switch to the web application class loader and back again respectively. The various elements of start and stop have to happen in a specific order so it is necessary to switch back and forth between class loaders.
Related
I need to log custom dimensions to Application Insights for which I'm using ILogger.BeginScope(). That works perfectly. That is:
using (logger.BeginScope(new Dictionary<string, object> { "key": "value" }))
{
logger.LogInformation("message");
}
My issue is that I need to call other methods in other classes, and I'm injecting the ILogger into all my classes. So how can I persist the logging scope among all my classes?
I could surely do ILogger.BeginScope() in all my classes, but I would need to pass the custom properties to classes that don't really need that information. Is there a pattern I could use?
If you call BeginScope multiple times in multiple classes within the same execution path, you will get one aggregated scope. There is no need to manually pass the properties. ILogger is injected as a singleton by default (see source code).
See also Since ILogger<T> is a singleton, how different threads can use BeginScope() without affecting others?
A call to BeginScope will put a new item onto that stack, and the adjoining Dispose will pop it off of that stack.
When the logger is invoked via LogInformation or otherwise, the data of the current stack object will be copied to write it to the console or whatever output that logger instance is configured to do.
LoggerExternalScopeProvider.cs#L14
I know how to add a Bean to a CDI container during AfterBeanDiscovery. My problem is that what I really need to do is the equivalent of adding a new producer method with the equivalent of a particularly qualified parameter.
That is, I'd like to somehow programmatically create several of these:
#Produces
#SomeQualifier("x")
private Foo makeFoo(#SomeQualifier("x") final FooMaker fm) {
return fm.makeFoo();
}
...where the domain over which SomeQualifier's value element ranges is known only at AfterBeanDiscovery time. In other words, some other portable extension has installed two FooMaker instances into the container: FooMaker-qualified-by-#SomeQualifier("x") and FooMaker-qualified-by-#SomeQualifier("y"). Now I need to do the equivalent of making two producer methods to "match" them.
Nonbinding is not an option; I want this resolution to take place at container startup, not at injection time.
I am aware of BeanManager's getProducerFactory method, but the dozens if not hundreds of lines of gymnastics I'd have to go through to add the right qualifier annotation on each AnnotatedParameter "reachable" from the AnnotatedMethod I'd have to create by hand (to avoid generics issues) make me think I'm way off the beaten path here.
Update: So in my extension, I have created a private static method that returns a Foo, and has a FooMaker parameter. I've wrapped this in a hand-tooled AnnotatedMethod that reports SomeQualifier("x") etc. in its getAnnotations() method, and also reports SomeQualifier("x") etc. from its AnnotatedParameter's getAnnotations() method. Then I got a ProducerFactory from the BeanManager and feed that into a new Bean that I create, where I use it to implement the create and destroy methods. Everything compiles and so forth just fine.
(However, Weld (in particular) blows up with this usage, which leads me to think that I'm doing Really Bad Things™.)
I need a way to share information between modules - not only between components in the same module -.
I have common data to share between the different moduleContext.
-I tried using the application context (moduleContext.getParentContext().setSettings() or getSettings(), but each module context has a different moduleContext.getParentContext().
-I also tried creating a singleton object for the application, but even in this case the singleton data of the first module (landing page) are not available for the other modules.
-The third thing I tried is to pass data via notifications (notify / listen), with the same results.
Does anyone knows how to solve this problem?
Marcos
If you want to keep relationship between the module tree, it is necessary that you create your module hierarchy by calling:
parentContext.loadChildContexts(moduleContexts);
When this is done, that method ensures the 'event mediator' of child contexts is set to the exact same 'mediator' instance of the parent context. Then an event occurring at any of the modules will be notified to all the contexts in the same module tress.
It is the same for settings as well. When 'loadChildContexts' method is used, the settings of the parent context are 'copied' to child context settings.
If it still doesn't work for you, can you share your code to me? I may help you to find where the issue is.
In Mojito on top of Node.js, I followed the example on http://developer.yahoo.com/cocktails/mojito/docs/quickstart/
What I did was renaming controller.server.js to controller.server-foo.js, and created a new file controller.server.js to show "Hello World".
But when mojito is started, the old file controller.server-foo.js is being used and so the "Hello World" is not printed. How come Mojito will use the old file?
(I also tried renaming controller.server-foo.js to foo-controller.server.js and now the "Hello World" is printed, but why is controller.server-foo.js used?)
I found out that historically, the "affinity" of the controller can be two parts. The first part is common, server, or client, and the second part is optional, and it might be tests, or other words, so use other names such as controller-not-used-server.js to disable it.
#Charles, there are 3 registration processes in mojito (yes, it is confusing at first):
Affinity (server, client or common).
YUI.add when creating yui modules (controllers, models, binders, etc)
and the less common which is the registration by name (which includes soemthing that we call selectors)
In your case, by having two controllers, one of them with a custom selector named "foo", you are effectible putting in use the 3 registration at once. Here is what happen internally:
A controller is always detonated as "controller" filename from the mojit folder, which is part of the registration by name, and since you have "foo" selector for one of the controller, your mojit will have to modes, "default" and "foo". Which one of them will be use? depends on the application.json, where you can have some conditions to set the value of "selector", which by default is empty. If you set the value of selector to "foo" when, for example, device is an iphone, then that controller will be used when that condition matches.
Then the YUI.add plays an important role, it is the way we can identify which controller should be used, and its only requirement is that NO OTHER MODULE in the app can have the same YUI Module name, which means that your controllers can't be named the same when registering them thru YUI.add. And I'm sure this is what is happening in your case. If they both have the same name under YUI.add() one will always override the other, and you should probably see that in the logs as a warning, if not, feel free to open an issue thru github.
To summarize:
The names used when registering YUI modules have to be unique, in your case, you can use: YUI.add('MyMojit', function(){}) and YUI.add('MyMojitFoo', function(){}), for each controller.
Use the selector (e.g.: controller.server-mobile.js) to select which YUI module should be used for a particular request by setting selector to the proper value in application.json.
I have created psedo code of what I would like to achieve. Inside of the SomeBLL().PerformBeginWork() threads will be created and maintained to do work. Using dot.net 4.0, what would be the best way to put this processing into an non-UI thread and still allow the assigned delegates to fire and update the UI in both a windows and web application without code modifications?
public class SomeBLL : BaseAsynWorker, IAsyncWorker
{
...makes threads and does work (if events are assigned then call them)
}
On a web page
SomeBLL sm=new SomeBLL();
sm.OnBeginWork+=ProcessUIUpdate;
sm.OnProgressUpdate+=ProcessUIUpdate;
sm.OnEndWork+=ProcessUIUpdate;
sm.OnHardError+=ProcessHardError;
SomeThreadClass.Spawn(sm.PerformBeginWork())
In a non UI process
SomeBLL sm=new SomeBLL();
sm.PerformBeginWork();
You're looking for the SynchronizationContext class.