I was trying to find a non-XML (Java Annotation/DSL) example of using timeout as a release strategy, but was unable to do so. (Such as TimeoutCountSequenceSizeReleaseStrategy...)
My goal is to release after some delay since the last correlated entry was added.
What you are looking for is called groupTimeout. See AbstractCorrelatingMessageHandler.setGroupTimeoutExpression().
If you are looking for the solution via annotation, you should consider to use AggregatorFactoryBean with the #ServiceActivator and #Bean annotations.
When we talk about Java DSL, there are groupTimeout()/groupTimeoutExpression() options on the CorrelationHandlerSpec when you configure an .aggregate(a -> ...) in the IntegrationFlow.
See Reference Manual for more information.
Related
Jakarta Faces 4.0 introduced a new #ClientWindowScoped annotation. However, searching the specification and implementations, I haven't found any example of its practical use in applications.
Maybe it's not only the case to annotate a bean with this annotation, but also to manipulate the jfwid request parameter through some provided API. If that's the case, can anyone provide a simple example of how it can be used or point to an article that does?
In JOOQ, when should I use Configuration.dsl() versus DSL.using(Configuration)? Both methods take a Configuration and return a DSLContext but it isn't clear from the documentation (or the implementation) if there's any practical difference. Are they the same? If not, how does one determine when to use one or the other?
For example, say I'm writing the run of a TransactionalRunnable, which is passed a Configuration. I need a DSLContext in order to perform some queries in the transaction. What is the correct method to use to obtain a DSLContext here?
In the DefaultConfiguration, they are the same. Configuration.dsl() is just convenience for DSL.using(Configuration). If you implemented your own Configuration, you could override this behaviour.
Granted, this could be mentioned in the Javadoc: https://github.com/jOOQ/jOOQ/issues/9289
This is follow-up on my earlier question How to set payload as constructor-arg value in service-activator.
We've 12 different classes like AProcessor, Bprocessor and so on.. and the each constructor accept common payload and execute same declared method in them 'publish'.
Now, I was thinking to have single common channel and service activator in SI which can handle this but then how can I put the class name in the expression dynamically which I can derive from the payload.type.
I was trying something like below but its not working
<service-activator input-channel="COMMON_PUBLISH_CHANNEL" expression="'new mypackage.'+payload.type+ 'RequestProcessor'(payload.myservice).publish(payload.data)">
</service-activator>
I want to save from writing 12 channels and service activators if I can do at one place.
I'd suggests to move such a logic into Java class and still have one <service-activator>. All the hard work to decide which target processor to invoke should be done there, in the service-method.
Spring Integration with its power to be so flexible with all those components and channels between them may lead to the misleading that it is programming language. When the real language is Java and we shouldn't forget its generic functionality.
Although we can achieve your wishes with Spring Integration anyway using SpEL magic:
<chain>
<header-enricher name="service" expression="#serviceRegistry[payload.type]"/>
<service-activator expression="headers[service].process(payload)"/>
<chain>
Are there any creational design patterns that allow for completely new objects (as in newly written) to be instantiated without having to add a new statement somewhere in existing code?
The main problem to solve is how to identify the class or classes to instantiate. I know of and have used three general patterns for discovering classes, which I'll call registration, self-registration and discovery by type. I'm not aware of them having been written up in a formal pattern description.
Registration: Each class that wants to be discovered is registered somewhere where a framework can find it:
the class name is put in an environment variable or Java system property, in a file, etc.
some code adds the class or its name to a singleton list early in program execution
Self-registration: Each class that wants to be discovered registers itself, probably in a singleton list. The trick is how the class knows when to do that.
The class might have to be explicitly referred to by some code early in the program (e.g. the old way of choosing a JDBC driver).
In Ruby, the code that defines a class can register the class somewhere (or do anything else) when the class is defined. It suffices to require the file that contains the class.
Discovery by type: Each class that wants to be discovered extends or implements a type defined by the framework, or is named in a particular way. Spring autowiring class annotations are another version of this pattern.
There are several ways to find classes that descend from a given type in Java (here's one SO question, here's another) and Ruby. As with self-registration, in languages like those where classes are dynamically loaded, something has to be done to be sure the class is loaded before asking the runtime what classes are available.
One things which I think here is that someone needs to do a new to your newly written Class. If you are not doing that then may be some framework needs to do that.
I could remember something similar which I did in one of my side projects using Java Spring . I had an interface and multiple implementations to it. My project required to iterate over all the implementations do some processing. Now for this even I was looking for some solution with which I would not have to manually do the instantiation of that particular class or some explicit wiring of that particular class. So Spring facilitated me to do that through #Autowired annotation. It injected all the implementation of that interface on the fly. Eg :-
#Autowired
private List<IMyClass> myClassImplementations;
Now in the above example I can simply iterate over the list of implementations injected and I would not have to do instantiation of my new implementation every time I write a new one.
But I think in most of the cases it would be difficult to use this approach (even though it fits in my case). I would rather go with a Factory pattern in general case and try to use that for creating new instances. I know that would require new but in my perception engineering it in a way that its object is automatically created and injected is a bit an extra overhead.
I am having a throuble about Spring AOP. I am trying to trigger a method using aspect but the method that will trigger the aspect is also the method of the same class and aspect is not working(No errors by the way).Like this
class A extends Runnable{
public void write(){
System.out.println('Hi');
}
public void run(){
this.write();
}
}
<aop:after-returning method="anyMethod" pointcut="execution(* A.write(..))"/>
Any ideas will be appreciated
Thanks
The fact that the advised method is called in a different thread doesn't make any difference. Just make sure the instance that you pass to the thread is created by the spring application context and not by your application code.
Also, since you're advising a method declared in a class, not an interface -- write() -- you'll need to perform load-time weaving (and have cglib in your classpath).
This is because Spring AOP is proxy based. You use a proxy to delegate calls to the underlying object. However, when an underlying object's method makes a call to another method inside it, of the same class (your use case) then proxy does not come into picture and hence what you are trying to achieve is not possible. There are some work arounds, but they kill the very purpose of AOP.
You can refer more information here.
http://docs.spring.io/spring/docs/3.1.x/spring-framework-reference/html/aop.html#aop-understanding-aop-proxies
As Abhishek Chauhan said, Spring AOP is proxy-based and thus cannot intercept direct calls to this.someMethod(). But the good news is that you can also use full-blown AspectJ within Spring applications via load-time weaving as described in the Spring manual. This way you can get rid of the limitation and even of the whole proxy overhead because AspectJ does not need any proxies.