I need the Spring Integration configuration to handle the case where there will be a variable number of queues which the application will receive messages on.
Have tried the following configuration:
<int-jms:message-driven-channel-adapter id="dsToT2"
destination-name="#{tConfigurer.getDsToTQueues().values().toArray().length>2?
dsConfigurer.getDsToTQueues().values().toArray()[2]:null}"
connection-factory="connectionFactory"
channel="ackToTChannel"/>
but, if the destination-name resolves to null, the following exception is thrown:
java.lang.IllegalArgumentException: 'destinationName' must not be null
What is the best way to handle this scenario?
Thanks
So, the problem is here that you get IllegalArgumentException on application startup.
If really don't know if your detination will be null or not, you shoudl do some Java code:
mark your <int-jms:message-driven-channel-adapter> with auto-startup="false"
Introduce separate bean for DefaultMessageListenerContainer with autoStartup=false too, and inject it to the <int-jms:message-driven-channel-adapter>
As far as destination-name is a property of that DefaultMessageListenerContainer you should right some code to resolve your destination on application startup and inject the value (if any) to the container bean.
And call start() of <int-jms:message-driven-channel-adapter>. It is a AbstractEndpoint bean with id dsToT2
Note, you can't provide null to the destination-name attribute. Your AC will fail on startup when it tries to populate bean properties. In this case will be called AbstractMessageListenerContainer#setDestinationName, which, in turn, does the check
Assert.notNull(destinationName, "'destinationName' must not be null");.
However, you can try to provide empty string '' instead of null and add similar SpEL condition for auto-startup attribute.
HTH
Related
I'm using Spring Integration and String Cloud Stream. I have a header that I want my HTTP gateway to use, which has a Long value, but it can't convert from Long to String by default and so displays the error Consider registering a Converter with ConversionService.
Therefore I tried adding my own LongToStringConverter class and the following Bean so that LongToStringConverter can be used:
#Bean
public ConversionService conversionService()
{
DefaultConversionService service = new DefaultConversionService();
service.addConverter( new LongToStringConverter() );
return service;
}
Then then received the following error: Dispatcher has no subscribers.
If I only return an instance of DefaultConversionService from the above bean I still receive the error.
When I remove the above bean and instead simply convert the Long value to String when setting the header value and that works without errors. Is it possible to use ConversionService instead? If so then how?
First of all there is already a ConversionService: https://docs.spring.io/spring-integration/docs/4.3.12.RELEASE/reference/html/messaging-endpoints-chapter.html#payload-type-conversion. And it has some set of predefined converters. So, you should consider to use #IntegrationConverter on the matter.
On the other hand it is unclear why do you need to do that at all. I wonder why Long.toString() isn't enough for you when you declare that header in first place.
I've started with SI and kind of stuck right now as we want to use SI in one of our existing project avoiding changes where we can.
A bean which we would be using as a service activator accepts an constructor argument of a java object.
that object is in the payload but then I'm unable to set it using inner bean usage of service-activator
<service-activator input-channel="ADMIN_TEST_CONNECTION" method="testConnection">
<beans:bean class="mypackage.request.AdminRequestProcessor">
<beans:constructor-arg value="payload"/>
</beans:bean>
</service-activator>
it's complaining about Could not convert argument value of type [java.lang.String] to required type.
Please help in how to access payload and set it as an constructor argument.
If I go via non- constructor arg route and change existing java object then it works with this call in the service activator
expression="#bean.testConnection(payload)"/>
but I don't wish you to change the existing java code until there is no other way.
I think you don't have choice unless change something or add code around existing.
Service-Activator performs its functionality against each incoming message in the input-channel. And that functionality is exactly method invocation where Message is used as a context for method arguments.
Not sure what you are going to do with that payload, but that doesn't look correct to use statefull object like your AdminRequestProcessor. Just don't forget that you may have many incoming message, but service-activator should be consistent.
Plus don't forget that <beans:bean> is singleton, so your AdminRequestProcessor is instantiated only once.
Looking to your sample I'd suggest something like this:
expression="new AdminRequestProcessor(payload).testConnection()"/>
If you really don't want to change anything in your code.
Everything rest you can find in the Reference Manual.
I replaced all of my JNDI lookups with JNDI.lookup() method because it seemed convenient, dealt with dynamic return types, etc. All was great...but now I just noticed that the checked exceptions that I had to catch before are no longer there.
I assumed this was because it would have just returned null if the JNDI variable didn't exist but it doesn't. It now just throws an unchecked exception.
Any idea why? Is there a way of just returning null for non-existant variables instead?
I created a bug for this on the omnifaces website: https://github.com/omnifaces/omnifaces/issues/141
Not sure if this is intended behavior or not.
Is there a way of just returning null for non-existant variables instead?
It does that for NameNotFoundException. The problem was here not in OmniFaces, but in the environment, which was GlassFish 4.1 in your specific case. It unexpectedly wrapped the NameNotFoundException in another NamingException, hereby causing the underlying NameNotFoundException to slip through and bypass the return null condition.
This has been fixed with help of Exceptions#is() utility method as per this comment. It will be available in OmniFaces 2.2.
After using Spring Integration in a project, my observation is to use jdbc adapter or gateway only at the start or end of the flow. If we use them in the middle of flow then it will become too verbose and complex.
For example:
<jdbc:outbound-gateway
query="select * from foo where
c1=:headers[c1] AND
c2=:headers[c2] AND
c3=:headers[c3] AND
c4=:headers[c4]"
row-mapper="fooMapper" data-source="myDataSource" max-rows-per-poll="100000" />
<int:service-activator ref="serviceActivator" method="processFoo" />
In the above <jdbc:outbound-gateway>, we need to pass all the placeholders (c1, c2, c3, c4) in the header of Message. We need to look back and forth in java code and xml file for any change in where condition or when there are too many where clauses.
It is also error prone. For example, if we misspelled :headers[c1] to :headers[d1] then it will not throw any exception and replace :headers[d1] with null.
If query does not return any row then it will throw exception by default. So, we have to use requires-reply="false" to change default behaviour.
If we want to proceed when query does not return any value then we have to add advice to gateway, as shown below:
<jdbc:outbound-gateway ... >
<jdbc:request-handler-advice-chain>
<bean class="com.service.NullReplyAdvice" />
</jdbc:request-handler-advice-chain>
</jdbc:outbound-gateway>
Please correct me if there are flaws in understanding of the concept.
We need to look back and forth in java code and xml file for any change in where condition or when there are too many where clauses.
It's true even for raw Java code around the JDBC: if you change the model you, of course, should change the SELECT, because it is just a String. And that's why there is a lot of work to make it type-safe - ORM, QueryDSL, Spring-Data etc.
if we misspelled :headers[c1] to :headers[d1] then it will not throw any exception and replace :headers[d1] with null.
That's because the headers is just a Map and it's truth that you get null, if there is no such a key in the map. To overcome that typo issue you can use POJO payload with getters, or some custom header, and again - the POJO with getters. In this case you end up with exception that there is no such a property against object. Although you'll see that issue only at runtime, not on compile. And again the same is with Hashtable - only at runtime.
So, we have to use requires-reply="false" to change default behaviour.
You should understand it at design time: allow or not to return nothing for the component.
The last idea is good. Wouldn't you mind to share your NullReplyAdvice?
Actually I achieve the same with <filter> before the JDBC gateway: to determine if there is something to fetch by count(*) query. From there I can lead my flow to the different logic, rather than the direct flow, when SELECT returns rows.
UPDATE
When you want to use Model object to keep business-specific values within Message, it's just enough to put this object to the header:
public class Foo {
private String foo1;
private String foo2;
public String getFoo1() {
return foo1;
}
public String getFoo2() {
return foo2;
}
}
...
MessageBuilder.withPayload(payload).setHeader("foo", foo).build();
...
<jdbc:outbound-gateway
query="select * from foo where
c1=:headers[foo].foo1 AND
c1=:headers[foo].foo2"/>
I am starter in mutithreading. I am trying to index my data into solr.For that I was writing the following code
I am getting null pointer exception in the line highlighted
You need to add the following:
<context:annotation-config/>
You need to set the path for autowiring package scan and in your case it will be:
<context:component-scan base-package="a.b.c" />
After it you need to mark the class as candidate for autowiring:
#Component("indexTask")
#Scope("prototype")
IndexTask implements Callable<IndexObject>
{
//ommited
}
Next you can remove indexTask bean configuration from xml file. your package will be created automatically.
Hope it helps.
Autowiring doesn't happen automatically, you need to configure it. See the Spring docs for detail, but essentially you need to add
<context:annotation-config/>