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.
Related
I am developing a new project with spring boot and graphql. I am confused on how to proceed because there are 2 ways to develop it, one is via the graphqls file and Annotation based approach. I prefer Annotation based approach but are they stable. exmaple : https://github.com/leangen/graphql-spqr.
I second AllirionX's answer and just want to add a few details.
Firstly, to answer your question: yes, SPQR has been pretty stable for quite a while now. Many teams are successfully using it in production. The only reason it is still in 0.X versions is the lack of documentation, but an occasional small breaking change in the API does occur.
Secondly, I'd also like to add that going code-first doesn't mean you can't also go contract-first. In fact, I'd argue you should still develop in that style. The only difference is that you get to write your contracts as Java interfaces instead of a new language.
As I highlight in SPQR's README:
Note that developing in the code-first style is still effectively
schema-first, the difference is that you develop your schema not in
yet another language, but in Java, with your IDE, the compiler and all
your tools helping you. Breaking changes to the schema mean the
compilation will fail. No need for linters or other fragile hacks.
So whether the API (as described by the interfaces) changes as the other code changes is entirely up to you. And if you need the SDL for any reason, it can always be generated from the executable schema or the introspection result.
I don't think there is a good or a bad answer to the "how to proceed" question.
There are two different approaches to build your graphql server (with graphl-java, graphql-java-tools, graphql-spqr), and each method has its advantages and inconvenients. All those library propose a springboot starter. Note that I never used graphql-spqr.
Schema first (with graphql-java or graphql-java-tools)
In this approach you first create a SDL file. The graphql library will parse it, and "all" you have to do is wire each graphql type to its data fetcher. The graphql-java-tools can even do the wiring for you.
Advantage
no need to enter into the detail of how the Graphql schema is built server side
you have a nice graphqls schema file that can be read and used by a client, easying the charge of building a graphql client
you actually define your api first (SDL schema): changing the implementation of the api will not require any change client side
Inconvenient
no compile-time check. If something is not wired properly, an exception will be thrown at runtime. But this can be negated by using graphql-java-codegen that will generate for you the java classes and interfaces for your graphql types, unions, queries, enums, etc.
if using graphql-java (no auto wiring), I felt I had to write long boring data fetchers. So I switched to graphql-java-tools.
Code first (with graphql-java or grapqhl-java-tools or graphql-spqr)
The graphql schema is built programmatically (through annotation with graphql-spqr or by building a GraphQLSchema object in graphql-java)
Advantage
compile-time check
no need to maintain both the SDL and the Domain class
Inconvenient
as your schema is generated from your code base, changing your code base will change the api, which might not be great for the clients depending on it.
This is my opinion on those different framework and I would be happy to be shown that I am in the wrong. The ultimate decision depends on your project: the size, if there is an existing code base, etc.
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
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.
I'm trying to improve my application. So I have installed perfino on my development server and it started to monitor my application. Now I would like to know the most slowest methods on my application. Where can I find that with perfino? I'm also trying to use jprofiler to find this information, but I'm kind of lost here.
Perfino does not work on the method level like a Java profiler, it measures "business transactions" that you can set up in the recording settings. Those are either web request, EJB calls or selected methods, either annotated with special annotations or configured as POJO methods in the recording settings.
For slow transactions, you can then look at method samples and find associated hot spots on the method level.
I'm thinking about a platform-neutral (i.e. not .NET MEF) technique of implementing chain-of-responsibliity pattern using web services as the handlers. I want to be able to add more CoR handlers by deploying new services and not compiling new CoR code, just change configuration info. It seems the challenge will be managing the metadata about available handlers and ensuring the handlers are conforming to the interface.
My question: any ideas on how I can safely ensure:
1. The web services are implementing the interface
2. The web services are implementing the base class behavior, like calling the successor
Because, in compiled code, I can have type-safety and therefore know that any handlers have derived from the abstract base class that ensures the interface and behavior I want. That seems to be missing in the world of services.
This seems like a valid question, but a rather simple one.
You are still afforded the protection of the typing system, even if you are loading code later, at runtime, that the original code never saw before.
I would think the preferred approach here would be to have something like a properties file with a list of implementers (your chain). Then in the code, you are going to have to have a way to instantiate an instance of each handler at runtime to construct the chain. When you construct the instance, you will have to check its type. In Java, for instance, that would take the form of instanceof (abomination ordinarily, but you get a pass for loading scenarios), or isAssignableFrom. In Objective C, it's conformsToProtocol.
If it doesn't, it can't be used and you can spit an error out to the console.