I have problem in creating a generic RequestContext that has common methods such as persist, update, remove and other Request classes extend this class. I got following exception :
com.google.web.bindery.requestfactory.server.ReportableException: Could not locate RequestContext operation
after some googling found this issue
and also this post.
and I think it's not resolved yet.
is there anyway to do this that I need not to repeat every method in all Request classes ?
Well, when a bug has been reported and is still open, then yes it's still not resolved, and as such, the workaround still applies. So no, there's no other way currently than re-declaring the methods in the subinterfaces.
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’m using jboss and cmt and have seen strange behaviour when using requires_new on an ejb method that I loop over from another bean to insert some records.
I see that intermittently after restarting the jboss the operations in the method aren’t committed to db after the method is finished.So, I have tried to use TransactionSynchronizationRegistry and found that when the data isn’t committed I actually don’t get a new transaction each time the method is entered. Anyone who has heard of jboss acting this way? I'm using ejb, jboss, jpa, Hibernate, cmt.
So, I've finally solved this problem. I used this great blog post
http://piotrnowicki.com/2011/11/am-i-in-the-same-transaction-am-i-using-the-same-persistencecontext/
to make sure that I actually was in the same transaction after entering the method annotated REQUIRES_NEW. So then I understood that JBoss intermittently ignored the annotation and defaulted to REQUIRED instead. This was because multiple classes implemented the same interface. So I simplified it so that I now have one interface, annotated #Local, and one implementing class where the REQUIRES_NEW annotated method is.
I understand that in this case it was our code that was wrong so it's not really a bug in Jboss way of handling transactions. But it's really strange that there isn't as much as a warning in the logs that there is a race condition. I could restart the Jboss and get a different behavior than before the restart. I think that's strange. I haven't found much about that this could be a problem after googling so I hope that this answer can save some time for someone else.
Edit:
It's not about multiple implementing classes, just about declaring all the methods in the interface annotated #Local, otherwise JBoss might ignore the attributes
Is it possible in Entity Framework CTP5 to construct retrieved persisted entities via an IOC container?
I'm using Ninject and it's tied in fine with MVC, but I need to inject some services into my domain objects when they are constructed for some business rules.
I'd rather do this using constructor injection than method or property injections.
I'm not sure what, exactly, you're trying to accomplish here, but EF has almost no extensbility points. The best you can do is hook into the ObjectMaterialized event fired by ObjectContext. In CTP5, you need to cast your DbContext like so in the constructor for your DbContext:
((IObjectContextAdapter)this).ObjectContext.ObjectMaterialized +=
this.ObjectContext_OnObjectMaterialized;
And then implement your function ObjectContext_OnObjectMaterialized(object sender, ObjectMaterializedEventArgs e). You will be able to access your object, which unfortunately has already been materialized. Depending on your needs, you might be able to hack in some interesting behavior here.
BTW, this sentence makes no sense to me:
I need to inject some repositories into my domain objects when they are constructed for some business rules.
Doesn't this go against Persistence Ignorant Domain Objects?
I tend to do the inverse of what you are trying to do. I make my domain objects as ignorant as possible (they are essentially property bags). When you need to perform some sort of action, like send an email, then I would use a service for that and have the method take in the domain object it needs to perform the action on. In this case, you would simply need to inject services into various parts of your application (which is much simpler to accomplish with Ninject).
I think EF code first CTP 5 can be of some help. It honours IValidatableObject interface, which takes ValidationContext object as an argument. The ValidationContext is a ServiceLocator so you should be able to get the instance of the IoC container using the validationContext object. (This is just my initial thought, I haven't tried anything though). Sorry, if my English is not very understandable.
Update
Sorry, just after I posted this comment I realized that the question is quite different than what I understood. So, I did try few things myself, and after some hit and trial and much more googling I was able to get somewhere. I was planning to post the answer here, but then thought against it, since the answer would be very long. So, I did post this blog instead.
http://nripendra-newa.blogspot.com/2011/02/entity-framework-ctp5-injecting-with.html
May be this might help some googlers searching for the same. Hope I got the question right this time.
#BeanProperty generates simple get/set methods. Is there a way to automatically generate such methods with support for firing property change events (e.g. I want to use it with JFace Databinding?)
I've had the same question, and have been keeping a close eye out for possible answers. I think I've just stumbled across one (although I haven't tried it yet). Scala 2.9 has a feature for handling dynamic calls (meant for integration with dynamic languages, I suspect). Essentially, calls to methods which don't exist are routed to a method called applyDynamic. An implementation of that method could use reflection to check that the method signature matches a property (possibly one with an annotation similar to #BeanProperty). If there is a match, it could handle firing the event.
Maybe that's something where a custom compiler plugin can do the trick.
Sadly I have no idea about how to write such a plugin. But at least thought I give you this pointer.
I would be very interested, if you'd come up with something along that line.
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.