Logstash has introduced a new plugin-mechanism with v1.5.0, where the plugins are fetched from rubygems.
For development what would be the proper way, running/debugging my own plugin without posting to rubygems for every change?
I got helped from first hand:
logstash issue #2265
Related
Im use a Elasticsearch 5.1.2 (docker installation) and integrated with a project generated with jHipster 4.0.2.
After configure Elasticsearch, Elastic show the message:
java.lang.IllegalStateException: Received message from unsupported version: [2.0.0] minimal compatible version is: [5.1.2]
sn_elasticsearch |
Its posible to upgrade the client version of Spring Data Elastic integration in jHipster project? Someone knows how to?
[]s
spring-data-elasticsearch does not support version 5 yet. It is a work in progress by a team of volunteers (not driven by the Spring Data team).
According to the latest post on GitHub where you can track the issue:
Given that we will look into upgrading elasticsearch to latest version and as #olivergierke suggested it will be released with Kay if we will be able to merge changes before RC1 which is in mid March [2017].
This pull request still require major week or two of a work, its not straight forward merge. We are independent resource(s) willing to contribute on this project wherever we can, anyone who is willing to do the same is more than welcome to contribute.
We will keep posting update from our side about upgrade on the same thread.
In my project I work with spring-boot and groovy. Also I using spring-boot-devtool. This is a good tool that helps me.
But, when I change groovy-files, server not restarted, I have to change other files
Like a IDE I use a IDEA. The project assembled and tested with the command
gradle bootRun
Has anyone experienced this and found a solution?
In my case pattern !?*.groovy was absent in Resource patterns in Compiler settings
Try with <CTRL+F9>
I am using Spring Boot 1.3.0-RELEASE with groovy only.
Maybe this auto-generated demo project may help you to compare what went wrong with your project, using Sring CLI (installed via SDKMAN):
run in command line: spring init --dependencies=devtools,web --type=gradle-project --language=groovy example
Import to IDEA
run gradle bootRun
change source and hit <CTRL+F9>
I've been trying to work through an issue that developed while attempting to upgrade our testing environment from 12.04 to 14.04 ubuntu on aws. Prior to this, the Package repository version of solr was 1.4.1 which matched our 1.4.1 solrj client integrated with our application.
Changing the base AMI to the 14.04 latest and running our default deploy caused solr 3.6.2 server to be installed. It appears it was accepting our configs without issue, however when our client tried to connect we received different errors:
The first was an unknown custom field, which we traced back to our deployment scripts not moving our schema.xml and solrconfig.xml to /etc/solr/conf/ but keeping it in the base directory.
We corrected this issue, and then ran into the following:
'exception: Invalid version or the data in not in 'javabin' format'
This was generated by a wrapper ontop of solrj, but I'll be honest and say I know nothing regarding Solr and that this may be on our end. I've asked our dev team to look at 2 options:
1) enabling: 'server.setParser(new XMLResponseParser());'
Which is the recommendation on the backwards compatibility for an older client.
2) updating our client in the application to 3.6.2
-I know less about the requirements on this.
My fall back is to revert to 1.4.1, but it appears it hasn't been touched since 2011, which makes me hesitant.
Any thoughts / suggestions would be appreciated!
Thanks!
I think the best option is to maintain the same version of Solr and Solrj.
I used for a lot of time Solr 1.4.1 and, while as you said, the most part of it works with newer versions without any problem, actually a lot of things have been changed since 1.4.*
I did your same porting last year, (from 1.4.1 to 3.6.1) and I can confirm you that the 2nd way is the right one: all changes you must do in your client code are just "formal" and very very quick.
Any workaround you could do for being able to communicate with a different version (between Solrj and Solr) is just, as the word says, a "workaround" and it could lead to unexpected (hidden) side-effects later.
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
I have CCValidator installed in 3 different locations (servers where CC.NET runs).
The problem that I have is that 2 of them do not recognize CC.NET plugins that I have installed - specifically conditional elements within the .config file. One version of CCValidator works as expected with conditional elements, but the other 2 do not.
The conditional elements are coming into use more and more often. I need to find updates for CCValidator to recognize the plugins I have and use regularly.
I did not install the various instances of CCValidator and can find nothing about downloading the newest version or updates. I have checked several posts that included links that did not lead anywhere that helped.
CruiseControl.net configuration validation tool is provided with ccnet installation. It has the same version as ccnet.
You should not install another version, as it is linked to your ccnet installation. If you have warnings or errors with the validator then :
be sure to use the right CCValidator.exe under the server folder (not inside ccvalidator).
upgrade your ccnet installation. v1.6.xxxx is stable enough and fix many thing from v1.5
For your information, I'm using ccnet v1.5.7385.122 and ccnet v1.6.7991.1 without any plugin error/issue.