I'm interested in running some code as soon as a Java application is started. I'm using AspectJ's load-time weaving and would ideally like to piggy-back on this.
Is there an event that I can hook into when an Aspect is registered?
if your using the standard aspectj syntax (not #AspectJ), then i believe all aspects should be new'ed, so you can simply do it in the constructor of the aspect.
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.
I was looking for the option to profile my APIs. I found Spring AOP is one of the options to profile the methods.
There are two options in Spring AOP to configure and use the aspects:
context:load-time-weaver
aop:aspectj-autoproxy
As per my understanding first option (load-time-weaver) performs weaving at load time without creating any proxy objects. And second option (aspectj-autoproxy) creates proxy objects. Am I correct on this? I believe, creation of proxy objects may hit the performance. wouldn't it?
Which option is best to choose considering better performance? What are the pros and cons of both approaches?
Well, Narendra, first of all there are profilers for profiling software. Maybe there is no need to code anything on your own.
As for your question: I have not idea how to configure Spring because I never use it. I am an AspectJ user. What I do know though, is that Spring AOP always uses proxies (JDK or CGLIB, depending on whether you need to proxy interfaces or classes). This is, as you said, something you probably do not want for profiling. AspectJ, no matter if you use compile or load time weaving, does not need or use proxies and thus should be faster. If you are not already using Spring in your project anyway, I would not touch it just to satisfy your profiling needs. Furthermore, Spring AOP only works for Spring Beans and just offers method interception, not much more. AspectJ is a full-blown AOP implementation and much more powerful. If you are already using Spring, you have a choice of using Spring AOP, AspectJ within Spring or a mixture of both.
I am working on an E4 RCP application and, while our basic DI configuration is working, I have some reservations about our current implementation.
The IInjector interface and #ProcessAdditions annotation are tagged as being discouraged for external access. Currently, we are using a series of statements similar to
injector.addBinding(IInterface.class).implementedBy(Concrete.class);
from within a method marked as #ProcessAdditions. What method(s) can be used that don't violate access rules? I know I can bind classes/strings to instances via IEclipseContext, but using ContextInjectionFactory by hand seems to force order of construction to be known by configurer (as opposed to other DI frameworks).
I know Guice has the concept of child injectors, but in E4, ContextInjectionFactory is internally set to use only the default injector for manufacturing. What is the best method to manufacture a group of objects, using DI, and subsequently disposing of this group? I would like to create a fresh batch of processing objects for each processing operation.
ContextInjectionFactory is the only thing I have seen described for doing injection in e4 (in Lars Vogel's 'Eclipse 4 RCP' book for example). This is what I use in my e4 applications.
Some things, such as #ProcessAdditions are marked as discouraged because that part of the e4 API has not been finalized yet and might change, they can still be used. #ProcessAdditions is only used for the application Life Cycle class.
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.
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.