Trying to understand how the retries are implemented, I'd expect to see something like threads in the source of Spring Retry - but don't. I'd like to know how retrying is implemented, if not as per threads.
Additionally I didn't find an #Aspect that would wrap the method to be retried. Since AOP is a dependency of Spring Retry - I would also expect to see some AOP-stuff. Where is that 'hidden'?
There is no threading; retries are invoked on the calling thread.
Spring Retry can be used in two modes:
In Imperative Mode you programmatically invoke the target code using a RetryTemplate.
In Declarative Mode you annotate public methods with #Retryable.
In this mode, #EnableRetry registers 2 beans RetryConfiguration (extends AbstractPointcutAdvisor) and AnnotationAwareAspectJAutoProxyCreator.
RetryConfiguration creates an Advice (AnnotationAwareRetryOperationsInterceptor) and AnnotationClassOrMethodPointcut.
Using these beans, Spring AOP uses the auto proxy creator to wrap beans with #Retryable annotations in a proxy with the interceptor advice.
Disclaimer: I am an AOP expert, not a Spring user.
Spring-Retry does not have a direct dependency on either of Spring-AOP, AspectJ or Spring-Aspects, only an indirect one via Spring-Core:
https://mvnrepository.com/artifact/org.springframework.retry/spring-retry/1.3.4
Have you seen class StatefulRetryOperationsInterceptor implements MethodInterceptor? There you have a dependency on classes from the org.aopalliance.intercept package. That mini library from AOP Alliance is like the smallest common denominator for Spring AOP, AspectJ and other interceptor-based approaches. It looks as if in this case we have manually implemented interceptors rather than full-fledged Spring AOP or AspectJ aspects.
Related
We are tying to use a WebService OutFaultInterceptor as per this blog post and it doesn't seem to work in JBoss 7.x.
The problem is simple in that it just ignores the #OutFaultInterceptor annotation. I tested this by putting in a erroneous interceptor name and it didn't error out. Logging within the interceptor is simply not called (when the interceptor name is correct).
I have also tried using the WEB-INF/jboss-webservices.xml to define out interceptors but that also seems to get ignored.
Removing the #Stateless annotation also does not seem to help.
This was working fine on JBoss 5.1 but simply seems to not work on JBoss 7.x. What am I missing here?
Is there an alternative way to "translate" exceptions into soap faults?
In order for using Apache CXF APIs and implementation classes you need to add a dependency to the org.apache.cxf (API) module and / or org.apache.cxf.impl (implementation) module.
Dependencies: org.apache.cxf services
According documentation:
When using annotations on your endpoints / handlers such as the Apache
CXF ones (#InInterceptor, #GZIP, ...) remember to add the proper
module dependency in your manifest. Otherwise your annotations are not
picked up and added to the annotation index by JBoss Application
Server 7, resulting in them being completely and silently ignored
See also: JBoss Modules
I hope this help.
Currently i enable UTF-8 as #Consumes("application/xml;charset=utf-8") in the RESTful Services for the different methods. I am interested to see if we can change this for all REST services with a single configuration change. We are using CXF, maybe there is something it provides?
Thanks
Ravi
The first question is are you sure you want to prevent any of your rest resources from accepting non-UTF-8 entities? Such an across the board proclamation feels like it could cause trouble down the road.
I'll admit that I haven't used CXF so I can't speak to those specifics. But I can think of one option each under the JAX-RS and Servlet APIs which might be along the lines of what you seek to accomplish.
Using the Servlet API: Depending on how you are deploying your application you might be able to create and inject a servlet filter. In the doFilter method, you can check the encoding of the request entity and continue on to the next part of the filter chain (ultimately to the rest application). If an improper entity is sent on the request, you would just set the appropriate HTTP 415 status onto the response and not invoke your rest application.
Using JAX-RS: Depending on how you parse/accept the entity body in your resources, you could create and inject a custom MessageBodyReader implementation. This reader could parse your entity, ensuring that it is UTF-8 only and throw an appropriate exception otherwise.
I try to get an application running which should interact with a server via RPC (JDO in Google DataStore). So I defined a persistent POJO on the server-side to get it put in the datastore via the PersistenceManager (as shown in the gwt rpc tuts). Everything works fine. But I am not able to receive the callback POJO on the client side because the POJO is only defined on server-side. How can I realize it, that the client knows that kind of object??
(sry for my bad english)
Lars
Put your POJOs in a separate package/directory (e.g. com.example.common) and then add source declaration to your GWT module descriptor (xyz.gwt.xml):
<source path="common"/> //relative to your xyz.gwt.xml location
GWT compiler will then also compile POJOs and they will be seen by your other GWT code.
Edited:
#Lars - now I understand your problem. As I see it you have several options:
If possible use Objectify instead of JDO. Objectify uses pure POJOs and they play nicely with GWT. I use this in my projects. One nice thing that Objectify gives you is #PostLoad & # PrePersist on methods to run some code before/after POJOs are loaded/saved to datastore. I use this to handle serialization of GeoPoint for instance.
Use JDO and make copies of your domain classes. This is a pain but it would work. Use 'transient' java keyword in your server JDO classes to exclude fields you do not want to RPC.
Edit #2: There is a third option that you might prefer:
Create "fake" JDO annotation classes using super-sourcing. This is a common technique to replace classes with a GWT version. Described here: http://fredsa.allen-sauer.com/2009/04/1st-look-at-app-engine-using-jdo.html
You can use DTO(stackoverflow, moar) for transferring data to client.
Basic sample here (method getTenLatestEntries() in your case).
Or you can use some third-party libraries like objectify and stop worry about making DTO`s.
First of all thanks to folks who are currently involved in the development of Camel, I am grateful for all the hard work they have put in.
I am looking for some design advice.
The architecture is something like this:
I have a bunch of Java classes which when instantiated are required to connect to each other and send messages using Apache Camel. The design constraints require me to create a framework such that all routing information, producers, consumers, endpoints etc should be a part of the camel-context.xml.
An individual should have the capability to modify such a file and completely change the existing route without having the Java code available to him.(The Java code would not be provided, only the compiled Jar would be)
For example in One setup,
Bean A ->Bean B->Bean C->file->email.
in another
Bean B->Bean A->Bean C->ftp->file->email
We have tried various approached, but if the originating bean is not implemented as a Java DSL, the messages rate is very high because camel constantly invokes Bean A in the first example and Bean B in the second(they being the source).
Bean A and Bean B originate messages and are event driven. In case the required event occurs, the beans send out a notification message.
My transformations are very simple and I do not require the power of Java DSL at all.
To summarize, I have the following questions:
1) Considering the above constraints, I do I ensure all routing information, including destination addresses, everything is a part of the camel context file?
2) Are there example I can look at for keeping the routing information completely independent of the java code?
3) How do I ensure Camel does not constantly invoke the originating bean?
4) Does Camel constantly invoke just the originating bean or any bean it sends & messages to irrespective of the position of the bean in the entire messaging queue?
I have run out of options trying various ways to set this up. Any help would be appreciated.
Read about hiding the middleware on the Camel wiki pages. This allows you to let clients use an interface to send/receive messages but totally unaware of Camel (no Camel API used at all).
Even better consider buying the Camel in Action book and read chapter 14 which talks about this.
http://www.manning.com/ibsen/
Save 41% on Manning books: Camel in Action or ActiveMQ in Action. Use code s2941. Expires 6th oct. http://www.manning.com/ibsen/
If you consider using ServiceMix of FuseESB, you might want to separate your routes in two parts.
First part would be the Event-driver bean that trigger the route. It could push messages to the ServiceNMR (see http://camel.apache.org/nmr.html).
The other part would be left to the framework users, using Spring DSL. It would just listen to message on the NMR (push by the other route) and do whatever they want with it.
Of course endpoint definition could be propertized using servicemix configuration service (see http://camel.apache.org/properties.html#Properties-UsingBlueprintpropertyplaceholderwithCamelroutes)
I'm trying to use Guice to inject properties of a JSF managed bean. This is all running on Google App Engine (which may or may not be important)
I've followed the instructions here:
http://code.google.com/docreader/#p=google-guice&s=google-guice&t=GoogleAppEngine
One problem is in the first step. I can't subclass the Servlet module and setup my servlet mappings there because Faces is handled by the javax.faces.webapp.FacesServlet which subclasses Servlet, not HttpServlet. So, I tried leaving my servlet configuration in the web.xml file and simply instantiating a new ServletModel() along with my business module when creating the injector in the context listener described in the second step.
Having done all that, along with the web.xml configuration, my managed bean isn't getting any properties injected. The method is as follows
#ManagedBean
#ViewScoped
public class ViewTables implements Serializable
{
private DataService<Table> service;
#Inject
public void setService( DataService<Table> service )
{
this.service = service;
}
public List<Table> getTables()
{
return service.getAll();
}
}
So, I'm wondering if there is a trick to get Guice injecting into a JSF managed bean? I obviously can't use the constructor injection because JSF needs a no-arg constructor to create the bean.
Check the following JSF-Guice integration framework/advice:
http://code.google.com/p/jsf-sugar/
http://notdennisbyrne.blogspot.com/2007/09/integrating-guice-and-jsf.html
http://cagataycivici.wordpress.com/2007/03/26/integrating_guice_and_jsf/
http://snippets.dzone.com/posts/show/7171
You can also create an HTTP servlet that then simple delegates the request on to a FacesServlet (like a wrapper). This should give you the same effect using Guice Servlet.
How about this approach, works well for us:
http://uudashr.blogspot.com/2008/12/guicing-jsf-with-guice.html
being the developer of jsf sugar I really would like to know the problem you had using it. We are already using it in production here so there shouldn't be any "show stoppers", maybe something is just not well documented? Just drop me a mail: murbanek(at)gmx_net (replace the _ with a .) .
check out http://code.google.com/p/guice2jsf/, and website starchu.blogspot.com, it has excellent library that provides Guice and JSF 2.0 integration
As information in this post are getting out of date but the question is still relevant, I'd like to share my findings about this topic. I wrote a little tutorial including a runnable sample project on how to setup a fully guice powered web stack. You can find it here: https://github.com/skuzzle/guice-jsf