Develop Reference

Why do I get Referenced bean nullChannel not found?

I usually get a warning about nullChannel not being defined in STS Problems view:
Referenced bean 'nullChannel' not found
But then if I add a declaration in context file, like <int:channel id="nullChannel" /> or <int:publish-subscribe-channel id="nullChannel">, I get an:
java.lang.IllegalStateException: The bean name 'nullChannel' is reserved.
I guess that's a warning I can safely ignore, but I usually try to zero out warnings, so is there something I'm missing?
UPDATE
These are the portions involved with the warning, removing them made it disappear:
<int:header-value-router input-channel="listOfMaps" header-name="transaction_type" resolution-required="false" default-output-channel="nullChannel">
<int:mapping value="52" channel="requests52ListOfMaps"/>
</int:header-value-router>
<int:service-activator input-channel="httpRequestsSendsChannel" output-channel="nullChannel" ref="conversionController" method="enable52Delivery" />
<int:service-activator input-channel="httpRequestsDeletesChannel" output-channel="nullChannel" ref="inspector" method="inspect" />

I am not sure why it was ok for me last week (probably pilot error) but I get it now with
<int:service-activator input-channel="errorChannel" output-channel="nullChannel" expression="foo" />
and, if I flip the in/out channels, the warning changes to errorChannel - the reason we don't get a warning for the input channel is because STS presumably knows that we will create input channels on the fly if needed.
I guess STS just doesn't know about these implicit beans.
I'll ask the STS guys if we can come up with a way to give them a list of implicit beans to suppress these warnings.
If that's not possible, we could consider relaxing the rule preventing the adding of a custom nullChannel bean.

Spring MVC : Asynchronous giving beancurrently in creation exception

I am working on a Spring-MVC application in which I want to use #Async at-least for the methods which are fire-and-forget. When I try to use #Async and I have used #EnableAsync annotation too for class, the actions inside the method are not performed. When I add task executor in servlet-context.xml, then I get an error bean is getting currently created. I am new to Async, can anyone tell me how I can use it.
I am not using Eager loading btw.
Error log :
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'groupNotesService': Bean with name 'groupNotesService' has been injected into other beans [mattachService] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.
Code :
GroupNotesServiceImpl :
#Service
#Transactional
#EnableAsync
public class GroupNotesServiceImpl implements GroupNotesService {
#Override
#Async
public void editGroupNote(GroupNotes mnotes, int msectionId) {
//Code to be executed, which is not getting executed
}
}
Servlet-context.xml :
<task:annotation-driven executor="executor" />
<task:executor id="executor" pool-size="20"/>
<mvc:annotation-driven />
<mvc:default-servlet-handler />
<resources mapping="/resources/" location="/resources/" />
If I remove any of the mvc lines above, I get a servlet.init() threw load exception error.
Also, Is it possible to use Async where I am returning int? I checked out the Future tag, but I don't know what modifications are required.
Here is the method that returns int.
#Override
public int saveGroupNoteAndReturnId(GroupNotes mnotes, int msectionid) {
// saves note and returns its id.
}
MattachService bean :
<beans:bean id="mattachDAO"
class="com.journaldev.spring.dao.GroupAttachmentsDAOImpl">
<beans:property name="sessionFactory"
ref="hibernate4AnnotatedSessionFactory" />
</beans:bean>
<beans:bean id="mattachService"
class="com.journaldev.spring.service.GroupAttachmentsServiceImpl">
<beans:property name="groupAttachmentsDAO" ref="mattachDAO" />
</beans:bean>
Edit
I checked out that there is a problem to run #Transactional and #Async both in one class. Jira SPR-7147. The workaround suggested there was to introduce a normal facade, and I really don't know what that means.

#EnableAsync should be in configuration, not the service itself. Since you seem to use xml configuration, check this https://stackoverflow.com/a/20127051/562721. It recommends to declare org.springframework.scheduling.annotation.AsyncAnnotationBeanPostProcessor to take care of #Async annotations

dynamically determining polling frequency in mule

I have been struggling to find a work around to be able to dynamically read the polling frequency in mule flow. Currently I am reading that from a file using spring's Propertyplaceholder at the start up and value remains the same even if the fie is changed(as we all know)..
Since poll tag needs to be the first component in the flow, There is nothing much i could do to read the "live" file update.
Is there any way I could set the polling frequency dynamically read from a file(without requiring restart)?
For Reference:
<spring:beans>
<context:property-placeholder location="file:///C:/Users/test/config.properties" />
</spring:beans>
<flow name="querying-database-pollingFlow1" doc:name="querying-database-pollingFlow1">
<poll doc:name="Poll3e3">
<fixed-frequency-scheduler frequency="${pollinginterval}"/>
<db:select config-ref="MySQL_Configuration1" doc:name="Perform a query in MySQL">
<db:dynamic-query><![CDATA[select empId,empName from employer where status='active';]]></db:dynamic-query>
</db:select>
</poll>
....</flow>

There is absolutely no issue with <fixed-frequency-scheduler frequency="${pollinginterval}"/> as you can dynamically read polling frequency from a properties file ...
The only thing I am concern here is :- <context:property-placeholder location="file:///C:/Users/test/config.properties" />
Since you are reading from a properties file outside your classpath, better try with the following :-
<context:property-placeholder
location="file:C:/Users/test/config.properties" />
One more thing .. if you are using Spring beans for properties file use the following way :-
<spring:beans>
<spring:bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<spring:property name="locations">
<spring:list>
<spring:value>file:C:/Users/test/config.properties</spring:value>
</spring:list>
</spring:property>
</spring:bean>
</spring:beans>

The clean way using FixedFrequencyScheduler is not there. You could potentially go to the registry, fetch your flow by name, then get the MessageSource and cast it to FixedFrequencyScheduler set the new interval and stop-start, however if you take a look to the code you'll see there is no setter for it and reflexion it's just too dirty.
My first choice would probably be to leverage a quartz endpoint and then leverage the quartz abilities to expose the configuration throught jmx/rmi.

I would definitely advise against using hot deploy to solve this problem especially if you need to change the frequency often. There is a risk that this will lead to problems with permgen running out of memory.
Instead you could use a flow with a quartz endpoint that fires at a relatively low frequency. Then add a filter that only lets through the message at the required frequency.
The filter can either watch a properties file for changes or expose attributes over JMX to allow you to change the frequency. Something like this.
<spring:beans>
<spring:bean id="frequencyFilter" class="FrequencyFilter" />
</spring:beans>
<flow name="trigger-polling-every-second" doc:name="trigger-polling-every-second">
<quartz:inbound-endpoint repeatInterval="1000" doc:name="Quartz" responseTimeout="10000" jobName="poll-trigger">
<quartz:event-generator-job>
<quartz:payload>Scheduled Trigger</quartz:payload>
</quartz:event-generator-job>
</quartz:inbound-endpoint>
<filter ref="frequencyFilter" />
<vm:outbound-endpoint path="query-database" />
</flow>
<flow name="query-database">
<vm:inbound-endpoint path="query-database" />
<db:select config-ref="databaseConfig" doc:name="Perform a query in database">
<db:dynamic-query><![CDATA[select empId,empName from employer where status='active']]></db:dynamic-query>
</db:select>
<logger level="ERROR" message="#[payload]"/>
</flow>

Separate route instances within single Camel context

I use Apache Camel module deployed inside ActiveMQ service.
Given I use Spring DSL and I have route definition ( implemented as routeContext) in the FilteringRouteContext.xml file (simplified):
<routeContext id="filteringRouteContext" xmlns="http://camel.apache.org/schema/spring">
<route id="myFilteringRoute">
<from uri="direct:filteringRoute"/>
<idempotentConsumer messageIdRepositoryRef="idempotentRepository" skipDuplicate="false">
<simple>${header.JMSType}</simple>
<filter>
<property>CamelDuplicateMessage</property>
<stop/>
</filter>
</idempotentConsumer>
</route>
</routeContext>
Next, I have configured Camel Context in other XML file (simplified):
<import resource="classpath:FilteringRouteContext.xml"/>
<camelContext xmlns="http://camel.apache.org/schema/spring">
<routeContextRef ref="filteringRouteContext"/>
<route id="myRoute1">
<from uri="activemq:topic:source1" />
<to uri="direct:filteringRoute" />
<to uri="activemq:topic:target1" />
</route>
<route id="myRoute2">
<from uri="activemq:topic:source2" />
<to uri="direct:filteringRoute" />
<to uri="activemq:topic:target2" />
</route>
<route id="myRoute3">
<from uri="activemq:topic:source3" />
<to uri="direct:filteringRoute" />
<to uri="activemq:topic:target3" />
</route>
</camelContext>
<bean id="idempotentRepository"
class="org.apache.camel.processor.idempotent.MemoryIdempotentRepository">
<property name="cacheSize" value="10"/>
</bean>
I would like to have shared route (with id=myFilteringRoute) from filteringRouteContext declared as, using IoC terminology, instance per dependency, so each route from single Camel Context (with id=myRoute1, myRoute2, myRoute3) should use it's own instance of that shared route (with id=myFilteringRoute), with separate internal state, bean instances, etc.
In other words, each route from Camel Context (with id=myRoute1, myRoute2, myRoute3) should not use the same instance of shared route (with id=myFilteringRoute), but should has its own completely separate instances (with completely separated internal states and bean instances )
Please consider that my shared route (with id=myFilteringRoute) may use more beans, which may have various scopes (singleton, prototype, request etc.).
My questions are: Can I achieve this goal using single Camel Context, or do I need to place my routes (with id=myRoute1, myRoute2, myRoute3) in separate Camel Contexts? What is the best solution of my problem?
Is there important performance impact If I use more than one Camel Contexts, and each context uses beans to communicate with ActiveMQ (org.apache.activemq.camel.component.ActiveMQComponent), or other beans that consume internal or system resources?
Or maybe it's better to resolve my problem by using Java DSL instead of Spring DSL?
Thank You.

Current Camel Spring DSL definitions are created by JAXB when it unmarshals the xml. This definitions help camel runtime to to build up processors and assemble them to route the message. In this way routeContextRef has nothing do with the scopes you mentioned.
But for the beans which you created by Spring with bean element, you can define the scopes if you like, and camel just grab it from Spring Application Context if there is bean reference in the Camel Spring DSL.
To answer you question, routeContextRef just give a way to share the route definition instance across the camel context, if you don't want share their instance you need to create the camel context in different spring application context which could hold the different instance of routeContext.

The answer is that Camel doesn't not provide an automatic mechanism for doing what you want to do. All routes in your example will share the same instance of idempotentRepository. The only solution is to provide a level of indirection.
For example, extend AbstractJdbcMessageIdRepository to provide your own implementation. This could then include the routeid in the look up to determine whether a message had already been processed.
Or you could have a set of repositories and look up which one to use from within the main idempotentRepository based on the route id.
Whatever you do, you'll need write code that uses the the route id of the outermost route to distinguish the messages.

How to turn off VelocityViewResolver errors in Spring?

I'm using Velocity and Spring. Within Spring, I'm using the VelocityViewResolver paired with the ContentNegotiatingViewResolver. For the most part, this works great. The only problem is that the ContentNegotiatingViewResolver queries the VelocityViewResolver with many different content sets (as it should).
When the Velocity engine doesn't find the particular template, an error is produced similar to the following:
2011-02-04 13:37:15,074 ERROR [http-8080-2] VelocityEngine: ResourceManager : unable to find resource 'foo.json.vm' in any resource loader.
This is not ideal. Ideally, if a template isn't found, a warning or something similar would be produced. If a template doesn't exist for a particular content type, I don't really care... as that means that content type isn't supported through that view resolver.
Any idea on how I could suppress this error though the VelocityViewResolver, VelocityView, or ContentNegotiatingViewResolver?

So, I found that the best way to do this was to add a logger statement to my log config file specifically for the Velocity engine (Velocity and my project both use Commons logging). My logger statement looks like this:
<logger name="org.apache.velocity.app">
<level value="OFF" />
</logger>

The problem will be fixed in Spring 3.2, see SPR-8640. After this improvement you will be able to configure Velocity view resolver to check unresolved views only once.

This happens because your ContentNegotiatingViewResolver uses VelocityViewResolver. You can stop it from doing that by giving it an empty (but non-null) list of view resolvers.
<bean
class="org.springframework.web.servlet.view.ContentNegotiatingViewResolver">
...
<property name="viewResolvers">
<list />
</property>
</bean>