This is a general question.
In my code, I'm calling some 3rd party library. In that library, there is a logger that outputs log messages using the log factory from org.apache.commons.logging. These log messages are appearing in my console, alongside all the other logs from my own code. Is there an easy way to disable printing of log messages from this external library? I don't want to change general logging configurations for my program, since I want all the other logging just the way it is.
Something like the pseudocode below would be useful:
ignoreLogsFrom {
// This call is the one that produces the logging
externalLibrary.get
}
Basically, being able to prevent any messages that emanate from a particular block of code or even library.
Thanks if you can point me in the right direction.
Yes, you can but it is hard to give a correct generic advice. The thins is that commons-logging is a wrapper library: it doesn't implement the logging itself, it delegates it to some other library.
Generally steps you have to do are:
Find out what logger implementation is used. By default it is Log4J but it might be something else (other popular choices include Logback or SLF4J which is another facade)
Find the name of the logger used by the external library. This is the parameter passed to the LogFactory.getLog call. Typically it would be something like the fully qualified name of the class that logs. This idea of naming is exactly the feature you want because it allows configuring loggers for different parts of the app differently.
Find out where the configuration for the library found #1 is stored. Typically it is some properties file or XML file (like log4j.properties)
Find out how the "level" for the given named logger is configured in that logging library. Most of the modern logging libraries support hierarchical configurations so it might easier for you to disable logging for the whole external library package rather than specific classes.
P.S. Probably disabling the whole logging for the library is not very good idea, it might be enough to raise the level to something like WARN or ERROR to significantly reduce the amount of logs but still not miss the really important st
Related
GWT's servlet implementation has onBefore/onAfterDeserialization which would give me a hook with which to start and stop transactions without doing anything fancy, however those methods don't allow me to properly check for error conditions after the service method got invoked, I just have access to the serialized return value, not directly to any exception that might have been thrown, so deciding whether to roll back or not is not possible that way without rewriting parts the GWT servlet.
I was thinking about using aspectj's compile-time weaving. However, this does not work with Netbeans' compile-on-save feature because the module needs to be recompiled using the aspectj compiler.
How about LTW (load-time-weaving)? Is there any way (or example) to add LTW to the webapp container without using the Spring framework?
I was also thinking about using AOP based on Java dynamic proxies, ie. to put a proxy in front of the servlet. Again, the question arises how to tell the Jetty WebApp container to load the proxy instead of the original servlet.
Or is there any ready-to-use solution out there already?
I think you could overwrite a combination of
public String processCall(RPCRequest rpcRequest) from RemoteServiceServlet and RPC.invokeAndEncodeResponse to do what you want.
Not ideal, as you need to copy/paste a few lines of code, but they really are only a few.
I myself hit the same problems as I needed some customizations, and relevant methods didn't had the access modifier that I needed, so I ended up copy/pasting some portions.
I can't comment on the rest of your question, but I don't expect to find any ready-to-use solutions, as GWT-RPC doesn't seem to have any new fans out there; just people maintaining legacy systems. Therefore, I expect that you either don't find anything or find solutions that are no longer maintained.
Looking at some of the sample code for hybrid mobile apps that speak to Node.js on BM (http://mbaas-gettingstarted.ng.bluemix.net/hybrid), you will see various examples that demonstrate how to use a logger on the client side:
var config = {
applicationId:'<applicationId>',
applicationRoute:'<applicationRoute>',
applicationSecret:'<applicationSecret>'
};
IBMBluemix.initialize(config).done(function(status){
// Initialize the Services
}).catch(function(err){
IBMBluemix.getLogger().error("Error intializing SDK");
});
I've confirmed this works fine in a Cordova app. My question is - why does this exist? As far as I can see, it does nothing more than wrap calls to console.log. It does not ever send logs to the Bluemix server app as far as I can tell.
There is documentation here, https://www.ng.bluemix.net/docs/starters/mobile/mobilecloud/nodejsmobile.html#log, that talks about the feature both server-side and client-side, but unless I'm missing it, there's no persistence for the client-side version.
If so - then what exactly is the point of this abstraction then? I have to imagine it was built for some reason, but I'm not seeing it.
this wrapper is used to "wrap" and to make "standard" the console log api, especially because this javascript API isn't available for all the browsers (especially old ones). By wrapping it the library could check the browser and its availability, in order to avoid an execution error
Another reasons is to wrap some configuration utilities, like providing different libraries to use (eg log4js) or other configuration, and so on.
Last but not least, probably it provide a singleton interface for performance optimization
I have the following problem:
1: An OSGI bundle A (equinox) is activated, and the activator parses an XML file
2: in the XML file, a declarative service is requested, which is present in another bundle (B)
3: bundle B is not activated yet, so the activator of bundle A needs to wait
I know how to approach this purely in DS, but the parsing needs to be carried out in the activator. Also I do not want to fool around with start levels and the likes. Ideally, I would want to be able to register the service provided by bundle B when needed.
Is there an elegant way to achieve this?
Thanks,
Kees
OSGi services are dynamic by nature and therefore you should never depend on the availability of a service. You need to use some kind of service tracking via a ServiceTracker or better, go for the pure DS solution which does all the hard work for you.
Since you indicate that you must parse the XML file, I guess you decided to use some kind of external configuration with services to use. I would suggest to re-consider this type of architecture. You need to write a lot of code while often the same goals can be reached by using a combination of the configuration admin and declarative services/blueprint.
How should the configuration for an IoC container be organized? I know that registering by code should be placed at the highest level in an application, but what if an application had hundreds of dependencies that need to be registered? Same with XML configurations. I know that you can split up the XML configurations into multiple files, but that would seem like it would become a maintenance hassle if someone had to dig through multiple XML files.
Are there any best practices for organizing the registration of dependencies? From all the videos and tutorials that I've seen, the code used in the demo were simple enough to place in a single location. I have yet to come across a sample application that utilizes a large number of dependencies.
Autofac and others (eg Ninject) employ a module concept for this exact purpose. http://code.google.com/p/autofac/wiki/StructuringWithModules may be what you're looking for.
Hth
Nick
It would help a little if we knew if you were talking about any particular IoC Container.
Windsor, for example, allows you to define dependencies across a wide range of XML files (organised however you want), and simply included in the configuration. The structure should be in a format that makes sense. Have a file/folder for Controllers, Facilities, etc etc. A heirarchy of related items.
With something more code-oriented, such as Autofac, you could easily create a host of container configuration providers to power your configuration. With Hiro, you don't really need to do much configuration at all.
Regardless of the container used, they all provide facilites for convention-over-configuration based registrations, so that should be your first stop in cleaning up registrations. A great example would be to register all classes whose name ends in 'Controller' in an MVC application.
At first I thought this would be question often asked, however trying (and failing) to look up info on this proved me wrong.
Is there a mechanism in Eclipse platform for centralized exception handling of exceptions?
For example...
You have plug-in project which connects to a DB and issues queries, results of which are used to populate some e.g. views. This is like the most common example ever. :)
Queries are executed almost for any user action, from every UI control the plug-in provides. Most likely the DB Query API will have some specific to the DB SomeDBGeneralException declared as being thrown by it. That's OK, you can handle those according to whatever your software design is. But how about unchecked exceptions which are likely to occur, e.g. , when communication with DB suddenly breaks for some network related reason?
What if in such case one would like to catch those exceptions in a central place and for example provide user friendly message to the user (rather than the low level communication protocol api messages) and even some possible actions the user could execute in order to deal with the specific problem?
Thinking in Eclipse platform context, the question may be rephrased as "Is there an extension point like "org.eclipse.ExceptionHandler" which allows to declare exception handlers for specific (some kind of filtering support) exceptions giving a lot of flexibility with the actual handling?"
You may override the public void eventLoopException(Throwable exception) from WorkbenchAdvisor
Quoted from its javadoc:
This method is called when the code
handling a UI event throws an
exception. In a perfectly functioning
application, this method would never
be called. In practice, it comes into
play when there are bugs in the code
that trigger unchecked runtime
exceptions.
Yes, Eclipse does provide a framework as you describe.
See http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/ua_statushandling_defining.htm for details of the extension point.
A starting point is to look at the default implementation: WorkbenchErrorHandler. You will need to implement your own class that extends AbstractStatusHandler. You might also like to look at InternalErrorDialog in the org.eclipse.ui plug-in. This displays the stack trace, which you probably don't want, but it extends ErrorDialog and provides an example that you can copy.