We Keep Coding

How to use an OnlineTSPSource with esig/dss Library?

I'm attempting to use an online timestamp authority (rfc3161) with the Digital Signature Service Java library. However, the following snippet (from their test cases, and similar to the one from their Cookbook):
String tspServer = "http://tsa.belgium.be/connect";
OnlineTSPSource otsp = new OnlineTSPSource(tspServer);
/* tried setting otsp.setDataLoader(new TimestampDataLoader());
too, as it defaults to otsp.setDataLoader(new
NativeHTTPDataLoader()); the exception happens in both cases */
byte[] digest = DSSUtils.digest(DigestAlgorithm.SHA1, "Hello world".getBytes());
TimeStampToken timeStampResponse =
otsp.getTimeStampResponse(DigestAlgorithm.SHA1, digest);
always ends with the following exception:
eu.europa.esig.dss.DSSException:
java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError:
org.apache.commons.io.IOUtils.closeQuietly(Ljava/io/Closeable;)V
Already tried many different public rfc3161 servers (some listed here). Sure there's something wrong going on there, but, as a beginner, I cannot understand what is wrong (what method should be there).
If anyone could put me in the right direction to get the snippet working (or even be kind enough to comment a reliable startup guide on cades/xades/pades with Java's bouncycastle) I would be really grateful.

As stated in the comments by Marteen Bodewes and Mark Rotteveel, there was something wrong with the version of Apache Commons-IO in the classpath. The project is set using Apache Maven and there was an old Commons-IO version declared there as a dependency. In this case, it was enough to remove that declaration, so Maven could download the appropriate version that was declared as an esig/DSS dependency.
esig/DSS version was 5.4 at the time.

Elasticsearch Java API from 2.x to 5.x issues

I've updated to elasticsearch java library version 5.2.0.
In 2.x,
I was using SearchRequestBuilder.addField() in order to add a field to the search request. Nevertheless, It seems to be replaced. I've written the available methods intellisense is showing me. Which of them do I need to pick?
addDocValueField
addFieldDataField
addScriptField
addStoredField
storedFields
fields
SearchRequestBuilder.setNoFields is also removed. Which would be the alternative?
Currently, I'm calling scripts from Java using this code. Is there any more elegant way to call it in 5.x Java API?
Code:
return AggregationBuilders
.terms(this.getName())
.field(this.getName())
.script(new Script(
ScriptType.FILE,
"painless",
"year",
ImmutableMap.of("field", this.getName())
)
);
As you can see I setting field as script parameter. Nevertheless, I don't quite understand how to get it from script code.
Thanks.

When in doubt, go to the source
use setFetchSource(String[] includes, String[] excludes) instead
use setFetchSource(false) instead
if you need to execute this script for each document, you can use addScriptField()

Add new webcontent version in Liferay

I would like to edit a webcontent (journalarticle) in Liferay and create a new version from that from a custom portlet. I call the JournalArticleLocalServiceUtil.addArticle() method with the following relevant parameters:
articleId = article.getArticleId();
autoArticleId = false;
version = article.getVersion()+0.1;
So the old articleId, and the version increased.
This code works in LR 6.1.30EE, but in 6.1.20EE and 6.1.1CE I got a DuplicateArticleIdException. Is this a bug in the earlier version? Is there a workaround or another method to create a new version of an existing webcontent programatically?
Minor question: what is the correct mode of increasing the version? The above +0.1 way creates from v1.1 v1.200000000000002, but simply v1.2 would be preferable.
Note:
updateArticle() method with a new version does not work either, it throws ArticleVersionException. It seems the right behavoiur as it should update already existing content.

OK, I find a solution meanwhile, thanks to some inspiration by Andew Jardin from Liferay Forums.
The solution is quite simple: call JournalArticleLocalServiceUtil.updateArticle(), but with the old version. Liferay automatically decides when to create a new version, and takes care of assigning the right version.

I got it solved by doing ,
double version = article.getVersion();
version = MathUtil.format(version + 0.1, 1, 1);
article.setVersion(version);

SVNKIT=> SVNUpdateClient.doCheckout method - pegRevision?

I am using SVNKit to checkout svn base repository. Earlier I was using checkout to head for that purpose I was using SVNRevision.HEAD. It was working fine without issue.
below is the syntax of same and revision.Head was used in case of checkout to Head.
doCheckout(SVNURL url,File dstPath,SVNRevision pegRevision,SVNRevision revision, boolean recursive)
but let say if I have to checkout to a specific revision for example 27988, what should be value of pegRevision parameter ?
I am confused please help, I tried HEAD/BASE for pegrevision and also same 27988 etc but it gives error like URL not exist etc .
Just an update, problem was with my code revision was going as 0 always due to some logic issue hence SVN URL was not found and giving error. I tried now with HEAD as pegRevision and 27988 revision works just fine. Thanks!

Well, first, you have to specify an SVNRevision, not an integer.
long targetRev = 27988;
SVNRevision revision = SVNRevision.create( targetRev );
doCheckout(...
As for pegRevision, you almost certainly want SVNRevision.HEAD. As the docs specify, it is:
the revision at which url will be firstly seen in the repository to
make sure it's the one that is needed
So, HEAD is usually sufficient. When it's not, things get complicated (and very specific), see the svn book.

Using chef to install Java 7, can't get it to work

I have a wrapper cookbook with one recipe in it, recipes/default.rb that reads the following:
include_recipe "apt"
node.override[:java][:jdk_version] = '7'
include_recipe "java"
I have the apt and java cookbooks from the community site. I'm running knife bootstrap with only this wrapper recipe.
When I converge the node, it installs Java 6 instead of Java 7. I feel like there's something obvious I'm missing, but I can't figure it out. Shouldn't the node.override make it so the default jdk_version of 6 is overridden?

Qualifying my answer with "I'm not a chef expert"... However, I think the issue is with "nested attributes" in Chef. I don't think you can just go ahead and override just the version, because after peeling over every possible thing that could be wrong with your piddly recipe, I found this:
http://lists.opscode.com/sympa/arc/chef/2012-10/msg00265.html
There's some other attributes that are being set after the default jdk version is set. If you look here:
http://community.opscode.com/cookbooks/java/source
You'll see default['java']['openjdk_packages'] gets set using that default version, and the openjdk recipe, which is likely the "install_flavor" being chosen, ONLY looks at that attribute. It doesn't read in the jdk_version directly. Interestingly, the java::oracle recipe (along with java::oracle_i386 and java::oracle_rpm) read in the version directly, so your initial attempt would have worked for that.
I would try setting the version with one of these, based on your particular platform:
Redhat/CentOS: node.override[:java][:openjdk_packages] = ["java-1.7.0-openjdk", "java-1.7.0-openjdk-devel"]
Debian/Ubuntu: node.override[:java][:openjdk_packages] = ["openjdk-7-jdk"]
Other "platform_family" choices can be found here: https://github.com/opscode-cookbooks/java/blob/master/attributes/default.rb

Here is how I got it to work with a wrapper cookbook.
I had to add this statement to the attributes/default.rb:
override[:java][:openjdk_packages] = [
"openjdk-7-jdk", "openjdk-7-jre-headless"
]
I tried adding the jdk_version in this location and it didn't work. I tried adding this statement (with node.override) in the wrapper cookbook recipe and it didn't work either.
Here is a description of why this is the case.