Spring 3.2.6
There might be an easy solution for this that I've missed, but I've been scouring the boards for the last couple days, tried a few things and so far nothing - so I thought I'd consult the experts.
My app:
I have 5 JaxWsPortProxyFactoryBean beans configured in my applicationContext.xml that connect to and consume various web services. Everything works fine, very nice!
Problem:
When my app starts there may be 1 or more web services that are either OFF or not accessible. This is fine as my app can run without them; however, is there a way to continue processing other beans in the context after receiving a TimeoutException (or any Exception due to connectivity with the WS)?
I was hoping for a property in JaxWsPortProxyFactoryBean like continueOnError or something similar.
Hope this makes sense.
You can disable the lookup/check of the web service at startup by setting the lookupServiceOnStartup property to false.
<bean id="yourService" class="org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean">
<property name="lookupServiceOnStartup" value="false" />
// Other properties
</bean>
Advantage your application starts up a bit faster, drawback the first call to the web service might take a little longer.
You can check the javadoc for more information, the lookupServiceOnStartup property is defined on the JaxWsPortClientInterceptor.
Possible solution is to use setLookupServiceOnStartup and set it to false.
http://static.javadoc.io/org.springframework/spring-web/3.2.6.RELEASE/index.html?org/springframework/remoting/jaxws/JaxWsPortClientInterceptor.html
Related
Versions:
Spring: 5.2.16.RELEASE
Spring Integrations: 5.3.9.RELEASE
macOS Big Sur: 11.6
For a fuller account of my spring-integration configuration, see this question I posted yesterday.
To sum up, I have set up this channel for polling changes to a directory:
<int-file:inbound-channel-adapter id="channelIn" directory="${channel.dir}" auto-create-directory="false" use-watch-service="false" filter="channelFilter" watch-events="CREATE,MODIFY">
<int-file:nio-locker ref="channelLocker"/>
<int:poller fixed-delay="${channel.polling.delay}" max-messages-per-poll="${channel.polling.maxmsgs}"></int:poller>
</int-file:inbound-channel-adapter>
It works fine. However, there does not appear to be a configuration option to start the polling after application-start by some arbitrary delay. In my case, I don't think there is any program error (yet) in starting the polling service immediately after Tomcat container starts my war-file. But it is also true that there is quite a bit going on during the application-start, and my preference would be to defer the inception of the polling service some time after the bean for SourcePollingChannelAdapter is created.
Is there anyway to do this in Spring?
There are (at least) a couple of options:
Instead of fixed-delay, use the trigger property to point to a PeriodicTrigger bean with an initialDelay (and fixedDelay).
Set auto-startup="false" and start the adapter manually either directly, or using a control bus.
https://docs.spring.io/spring-integration/docs/current/reference/html/system-management.html#control-bus
ClassCastException occurs when I try to scan a large number of keys
using opsForHash.scan() method. I am using Jedis 2.6.2 and I face this
error only when the number of keys to be searched is large(~100,000).
I have read solutions to this problem online and most of them are
suggesting that the problem occurs due to connection pooling.
I am using Spring integration in my project and have set use-pool attribute as true(in JedisConnectionFactory) even though it is the default option.
Since spring is supposed to manage the connections with redis, why am I still having this issue?
Please suggest.
This is the Spring Configuration file I am using :
This is the java code where i am executing scan() :
I had this same problem. After searching a lot on the internet, I found that the problem occurs due to connection pooling problems. As you have mentioned, you have set use-pool to be true in the spring configuration.
I by passed this problem by setting pooling as false. It turned out that I didn't need pooling and after that the problem didn't occur.
You can try this solution if you don't explicitly need pooling.
Here is the code snippet:
<bean id="jedisConnFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory"
p:hostName="" p:port="6379" p:usePool="false" />
Hope it helps!
I've seen many incarnations of this same issue but I think I've tried all the fixes - my usage is quite straightforward.
I had been using Ehcache which also didn't work. So, to rule out Ehcache issues and help point to something more fundamental, I moved to SimpleCacheManager and ConcurrentMapCacheFactoryBean.
Here's my config:
<cache:annotation-driven/>
<bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
<property name="caches">
<set>
<bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="parentAppIds"/>
</set>
</property>
</bean>
Here's my method:
#Cacheable(value="parentAppIds", key="accountNumber")
public Long findApplicationId(String accountNsc, String accountNumber) throws EMSException {
....
}
This is a method on an interface, who's implementing class is Spring managed #Service("foo")
I tried using 'p0' as is suggested here but to no avail. I have no compilation problems and no errors in my server logs so I'm confident that I have all that is necessary on my classpath; and that Namespaces are all fine, since I'm using STS for that - so I left out pom.xml and spring Namespace declarations to block noise.
I'm using Spring 3.1; Java 1.5 and Websphere 6.1
The symptom is that the method is being visited with the same parameters repeatedly.
Please help - I'm hungry and refuse to go for lunch until I nail this.
note: I have simplified my #Cacheable declaration my actual one is
#Cacheable(value="parentAppIds", key="#p0.concat('-').concat(#p1)")
Neither work.
Thanks.
** Edit - I've ruled out Websphere as being a problem by creating a test rig with
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(...)
which mimics what is happening. #Cacheable is simply not working. There must be something blindingly obvious that I am missing. (I've had lunch now)
My issue is resolved. Unfortunately I cannot pinpoint exactly where my issue lay. Certainly, all that is required is that which I have mentioned in my question.
TO fix this, I tidied up my Spring configuration a bit and cleared my browser and application server cache and temp directories. I did a full clean install and cache is now working.
It is possible that I was testing with an earlier version which did not include this important line in the application config:
<cache:annotation-driven/>
I had omitted that at the start. Maybe my adding of that was not picked up until now. Otherwise I am stumped. Thanks for your time.
Did you perhaps change
#Cacheable(value="parentAppIds", key="accountNumber")
to
#Cacheable(value="parentAppIds", key="#accountNumber")
as adding the # that removed one error for me while trying to get caching working.
so I'm new to Spring Integration, and mostly to Spring as well, so I might not be up on all of the terminology, but I'm running across the following scenario:
I have a small Spring Integration application with three SI flows... each flow has its own Gateway, and each Gateway has its own request channel and reply channel. These flows receive a null invocation (for all intensive purposes... basically just a 'GO' signal / empty message) and reply with a status message, depending upon the (trivial) business logic results.
I would now like to wire each of these flows together to run in one 'master flow', given one request, without taking away their ability to run separately, and I'd like to wire it up completely through annotation / XML (IE. given a controller that invokes the main gateway's service interface, no additional code needs to be written outside of annotation / XML configuration.)
Is this feasible, what Integration components should I be using to do so, and/or should I just be adjusting the expected channels for each of these gateways to be meeting each other end-to-end (and if so, how would that strategy compensate to allow each of the flows to be called on a case-by-case basis)?
In addition, if this is not feasible, would it be appropriate to use a service activator to invoke each of the child flows? I wanted to avoid coding more, but if that is the only option, I guess that it'll have to do.
Thanks!
Probably the simplest way to do this is use Spring Profiles (a Spring 3.1 feature). When deployed in stand-alone mode, the final element can be a "bridge to nowhere"...
<int:bridge input-channel="app1Final" />
... when the final element in a flow has no output channel, the message is returned to the gateway's reply channel. If you prefer to explicitly configure the bridge to point to the gateway's reply-channel, that's ok too; it just not needed.
In the "linked" profile, you configure the bridge thus...
<int:bridge input-channel="app1Final" output-channel="app2Inbound"/>
...where app2Inbound is the same as that app's gateway's request-channel.
<beans profile="default">
<int:bridge input-channel="app1Final" />
</beans>
<beans profile="linked">
<int:bridge input-channel="app1Final" output-channel="app2Inbound"/>
</beans>
To run with the linked profile, set system property 'spring.profiles.active' to 'linked'
I am working on an old application which has huge code from legacy.
Application is based on Spring 2.0 and using Acegi plugin for security. The Tomcat server is successfully configured on HTTPS port.
Now I need to redirect the login over HTTPS. I tries setting following in my template_spring_config.xml
<bean id="authenticationEntryPoint" class="src.auth.acegi.myAuthenticationProcessingFilterEntryPoint">
<property name="loginFormUrl" value="http://#domain.name#/welcome"/>
<property name="forceHttps" value="true"/>
</bean>
Help found so far indicates that this much should be enough to redirect on HTTPS. But this is not working at all and my Request for login remains on HTTP.
I cannot switch to Spring-Security and higher Spring versions due to time constraint.
Please help if you know what else I need to do.
It's difficult to say for sure since you are using a custom entry point implementation (which may behave differently), but you are using an absolute URL, which will probably override the default logic for building the redirect. Try using https:// rather than http:// for your login URL scheme.
Note that you really shouldn't be using Acegi since development stopped on it a long time ago. It contains most (possibly all) of the vulnerabilities that have subsequently been patched in Spring Security. The same goes for Spring itself.