We're using Camel's File component to receive files that are placed into a directory. The URI for this is similar to:
file:///some/directory/inbox?delay=30000&delete=true&include=DSINV.*%5C.OUT&preSort=true&readLock=changed&readLockCheckInterval=5000&readLockMinLength=0
previously we did not have the 'preSort=true' parameter, and files were being received in a random order.
We added this parameter, but we are now getting the following error in the logs:
There are 1 parameters that couldn't be set on the endpoint.
Check the uri if the parameters are spelt correctly and that they are properties of the endpoint.
Unknown parameters=[\{preSort=true}]
The version of Camel we are using is 2.15.4. The documentation for the 2.x version of the File component states that this is a valid parameter.
This has been added in 2.21.0
https://camel.apache.org/releases/release-2.21.0/
See the related jira here
https://issues.apache.org/jira/browse/CAMEL-11656
So it is not available in 2.15.4 you have to at least update to 2.21.0 in order to work.
I don't know about the latest but is seems even the most resent Camel versions still support java 8
https://camel.apache.org/manual/latest/index.html#_jdk_requirements
Camel 2.x supports JDK 8
Camel 3.0 - 3.4 supports JDK 8 and 11
Related
Versions 1.15.3 and earlier stored the Flow Configuration in flow.xml.gz, and version 1.16.0 introduced a new serialization format stored in flow.json.gz. As a result of changes in version 1.17.0 to support Sensitive Dynamic Properties, components can be marked as invalid when the Flow Configuration contains a Parameter Context with a Sensitive Parameter Value that is referenced in a Sensitive Property. This issue can be resolved by entering the Sensitive Parameter Value in the referenced component Sensitive Property, which will save the Flow Configuration using the new flow.json.gz format. As an alternative, first upgrading to version 1.16.3 and then upgrading to 1.17.0 also avoids invalid component status issues.
How should I migrate flow.xml.gz to flow.json.gz, whether to automatically transition or to change the file name to flow.json.gz when migrating the old version of flow.xml.gz？
cruise6, changing the file name to flow.json.gz from the old version of flow.xml.gz will not work, as they are two different formats.
The other alternative you suggested, i.e. automatically transition will work fine.
I migrated from 1.15.1 to 1.16.1 and in the 1.15.1 I only had flow.xml.gz file. After I restarted with the upgrade I see two files flow.xml.gz and flow.json.gz. Both files are updated as I make changes to the flows. But at some point the xml version will go away.
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.hibernate.search.elasticsearch.client.impl.DefaultElasticsearchClientFactory.createClient(DefaultElasticsearchClientFactory.java:92)
The following method did not exist:
org.elasticsearch.client.RestClientBuilder.setMaxRetryTimeoutMillis(I)Lorg/elasticsearch/client/RestClientBuilder;
The method's class, org.elasticsearch.client.RestClientBuilder, is available from the following locations:
jar:file:/home/temp/.gradle/caches/modules-2/files-2.1/org.elasticsearch.client/elasticsearch-rest-client/7.10.2/d0c857275bcec532079cdabb7913e2611c123e70/elasticsearch-rest-client-7.10.2.jar!/org/elasticsearch/client/RestClientBuilder.class
The class hierarchy was loaded from the following locations:
org.elasticsearch.client.RestClientBuilder:
file:/home/temp/.gradle/caches/modules-2/files-2.1/org.elasticsearch.client/elasticsearch-rest-client/7.10.2/d0c857275bcec532079cdabb7913e2611c123e70/elasticsearch-rest-client-7.10.2.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of org.elasticsearch.client.RestClientBuilder*
We need to use elasticsearch version 7.10.2 and currently we are using springboot version 2.3.9
any help?
is this correct mapping in application.yaml file for elastic search 7.10.2
hibernate:
format_sql: true
search.default:
elasticsearch:
dynamic_mapping: true
index_schema_management_strategy: update
required_index_status: yellow
https://stackoverflow.com/users/6692043/yrodiere
The version of the elasticsearch-rest-client dependency (Elasticsearch's low-level REST client) does not have to match the version of Elasticsearch server you actually use. elasticsearch-rest-client 7.16.3 will talk just fine to Elasticsearch server 7.10.2. And elasticsearch-rest-client 7.16.3 is licensed under ASL 2.0, if that's what you're worried about.
So, in short: do what the Hibernate Search documentation suggests, and upgrade to the latest version of elasticsearch-rest-client. See https://docs.jboss.org/hibernate/search/6.1/reference/en-US/html_single/#gettingstarted-framework-spring-boot-dependency-versions :
Spring Boot automatically sets the version of dependencies without your knowledge. While this is ordinarily a good thing, from time to time Spring Boot dependencies will be a little out of date. Thus, it is recommended to override Spring Boot’s defaults at least for some key dependencies.
With Maven, add this to your POM’s :
<properties>
<hibernate.version>5.6.5.Final</hibernate.version>
<elasticsearch.version>7.16.3</elasticsearch.version>
<!-- ... plus any other properties of yours ... -->
</properties>
If you use Elasticsearch's high-level REST client, now... you're in a pickle. That client is no longer open-source and can cause licensing issues. And its last open-source version (7.10.something) may not work with elasticsearch-rest-client 7.16.3. So if you really need to stick with version 7.10 or earlier of the high-level REST client, then you'll need to use older versions of elasticsearch-rest-client and Hibernate Search.
I have the following situation when migrating and compiling in native mode a quarkus service from version 2.5 to 2.6 and it is the following:
We have a JAR which contains the definition of traversal objects used by several services, within these are the validation messages used in the javax.validation.constraints annotations defined in a file called ValidationMessages.properties
Until version 2.5 I could include this jar as part of the service dependencies, it performed the native compilation of the service and managed to load these messages through the context without any additional configuration.
Now when migrating to version 2.6 it is not able to locate the default file but always looks for one depending on the region of the system:
The specific message is the following:
java.util.MissingResourceException: Can't find bundle for base name ValidationMessages, locale es_MX
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:2055)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1689)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1593)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:1284)```
After upgrading to quarkus version 2.7.3 I no longer have this issue.
spring data elasticsearch uses 7.x client version and my production elasticsearch version is 6.4.2. So I changed the version and got the following exception. How to safely change version in spring data es?
Repopsitory: https://github.com/Yungdi/spring-data-reactive-elasticsearch
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.springframework.data.elasticsearch.core.ReactiveElasticsearchTemplate.<init>(ReactiveElasticsearchTemplate.java:108)
The following method did not exist:
org.elasticsearch.action.support.IndicesOptions.strictExpandOpenAndForbidClosedIgnoreThrottled()Lorg/elasticsearch/action/support/IndicesOptions;
The method's class, org.elasticsearch.action.support.IndicesOptions, is available from the following locations:
jar:file:/Users/we/DevEnv/gradle-6.4.1/caches/modules-2/files-2.1/org.elasticsearch/elasticsearch/6.4.2/29a4003b7e28ae8d8896041e2e16caa7c4272ee3/elasticsearch-6.4.2.jar!/org/elasticsearch/action/support/IndicesOptions.class
The class hierarchy was loaded from the following locations:
org.elasticsearch.action.support.IndicesOptions: file:/Users/we/DevEnv/gradle-6.4.1/caches/modules-2/files-2.1/org.elasticsearch/elasticsearch/6.4.2/29a4003b7e28ae8d8896041e2e16caa7c4272ee3/elasticsearch-6.4.2.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of org.elasticsearch.action.support.IndicesOptions
You can’t use a Elasticsearch 6 cluster with Spring Data Elasticsearch 4 which uses Elasticsearch 7 libraries. The Elasticsearch REST API that is used had breaking changes between version 6 and 7.
You can try to use Spring Data Elasticsearch 3.2.x which targets 6.8; I currently don’t know if there were breaking changes between Elasticsearch 6.4 and 6.8, you’ll have to try it.
I have installed WildFly 10.1.0.Final I I created a Stomp over Websocket client to in Javascript to connect directly to a topic in Artemis.
I connect an subscrite two clients but when I close or unscribe one of the two clients, the others spot recive messages.
I found a mail-list that have exactly discribing the same problem.
http://activemq.2283324.n4.nabble.com/STOMP-server-quits-sending-to-all-subscribers-when-one-client-disconnects-td4713980.html
One user called "johndament" mention that the auto creation feature fixes this error (in v1.3). Then "Ed Kaltenbach" solve the problem updating the ActiveMQ artemimis version from v1.1.0 that is shipped with wildFly 10.1.0.Final to v1.3
Can helpme to update the version and recommendations?
These are the files after download and unzip ActiveMQ 1.3 from the official site:
The following instructions work for updating to Artemis 1.3.
Note that I also tried this for Artemis 1.5, this did NOT work....
1) copy apache-artemis-1.3.0/bin/lib/* to wildfly-10.1.0.Final\modules\system\layers\base\org\apache\activemq\artemis\main\lib (replace the existing *.so files)
2) copy all Jars from apache-artemis-1.3.0/lib to the corresponding subdirectory in wildfly-10.1.0.Final\modules\system\layers\base\org\apache\activemq\artemis. Copy all files to the location where you find a Jar file with the same name but different version. Remove the old Jar files, and make sure you also change the version numbers in the respective module.xml.
Some files from apache-artemis-1.3.0/lib don't have a corresponding file in wildfly-10.1.0.Final\modules\system\layers\base\org\apache\activemq\artemis. You can ignore these files.