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);
Related
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.
I'm using Moneta JavaMoney 1.3 to obtain an exchange rate:
CurrencyUnit base = Monetary.getCurrency(...);
CurrencyUnit term = Monetary.getCurrency(...);
ExchangeRateProvider xrates = MonetaryConversions.getExchangeRateProvider();
ExchangeRate xrate = xrates.getExchangeRate(base, term);
If I run the code within Eclipse it works fine. But after building a jar with Maven and running the jar from the command line, ExchangeRateProvider.getExchangeRate(base, term) returns null.
I also tried specifying the ExchangeRateProvider: ExchangeRateProvider xrates = MonetaryConversions.getExchangeRateProvider("ECB"); Within Eclipse all ok, from the command line it throws an MonetoryException saying "Invalid ExchangeRateProvider (not found): ECB"
This question mentions the same issue: "Because if i'm using dependency on money-api without bp I get null as an result." I tried the accepted answer:
ConversionQuery cq = ConversionQueryBuilder.of().setBaseCurrency(Base).setTermCurrency(Term).build();
MonetaryAmount zero = FastMoney.zero(Base);
ExchangeRateProvider xrates = MonetaryConversions.getExchangeRateProvider("ECB");
CurrencyConversion cc = xrates.getCurrencyConversion(cq);
ExchangeRate xrate = cc.getExchangeRate(zero);
Again no luck: works within Eclipse, but returns null from the command line. Does this have something to do with dependencies when building the jar? I'm using the Maven shade plugin with minimizing turned off.
Or should I use moneta-bp too? Would be strange, since moneta-bp is built as backport for Java 7, and I'm using Java 8. Any other ideas?
Thanks in advance!
EDIT:
Running from Eclipse the ExchangeRateProvider is an instance of org.javamoney.moneta.spi.CompoundRateProvider. From the command line it's an instance of org.javamoney.moneta.convert.internal.IdentityRateProvider. Looking at IdentityRateProvider's code, it makes sense that it returns null. But how to get the CompoundRateProvider?
Instead of using the Maven shade plugin, I tried this solution and it seems to work now.
I have to refactor and migrate legacy code from pre 2010. Documentation is bad and I am pretty new to RCP and BIRT coding as well.
The thing is, that we replaced the broken ant build process with a maven tycho process and we got a running application. Now i need to fix a report which somehow does not get displayed and we dont know why.
ExtendedItemHandle eih = elementFactory.newExtendedItem( null, "Chart" );
The newExtendedItem method returns null for some unknown reason and I cant figure out why. Since the code is so old i figured it may have something to do with the target platform, but I dont know where to look. Any suggestions?
EDIT:
I should probably give some context:
// A session handle for all open reports
SessionHandle session = new DesignEngine( null ).newSessionHandle( (ULocale) null );
// Create a new report
reportDesignHandle = session.createDesign( );
// Element factory is used to create instances of BIRT elements.
elementFactory = reportDesignHandle.getElementFactory( );
It was a missing plugin. I dont know, which one, but eventually adding the whole target platform to my running configuration fixed it.
i update the opengl version.
But i got an error :
AWTGLPixelBuffer pixelBuffer = pixelBufferProvider.allocate(gl,
AWTGLPixelBuffer.awtPixelAttributesIntRGB3,
v.getWidth(),
v.getHeight(),
1,
true,
0);
My library could not find awtPixelAttributesIntRGB3 . If i use old version, it can find that.
I import the same library : import com.jogamp.opengl.util.awt.AWTGLPixelBuffer;
Last thing, i downloaded last version of opengl here (jogamp-all-platforms.7z) :
http://jogamp.org/deployment/jogamp-current/archive/
And i only add jogamp-all.jar to my lib folder.
Thanks in advice.
You give us very little information on what's going on.
E.g. we don't even know from what version to which new one you upgraded.
I guess your problem is that the field awtPixelAttributesIntRGB3 was removed from version 2.2 to 2.3.
The API documentation of GLPixelBuffer.GLPixelBufferProvider#allocate explains quite well how to use it.
The key is that you need to fetch pixelAttributes differently, e.g. via getAttributes(GL, int, boolean).
I tried to use an ObjectAutoCompleteBuilder to build ObjectAutoCompleteField as below:
ObjectAutoCompleteBuilder builder = new ObjectAutoCompleteBuilder(provider);
builder.autoCompleteRenderer(renderer);
final ObjectAutoCompleteField autocompleteField = builder.build("searchResource" , new Model());
final TextField searchResource = autocompleteField.getSearchTextField();
searchResource.setRequired(true);
but it has thrown this exception :
java.lang.NoSuchMethodError: org.apache.wicket.AttributeModifier.append(Ljava/lang/String;Ljava/io/Serializable;)Lorg/apache/wicket/behavior/AttributeAppender;
Does anyone have any idea why?
You're using the wrong version of Wicket (1.4.17) for the WicketStuff project you're using (1.5.4).
From the WicketStuff wiki:
Our release process allows end users an easy way to track a project relative to the wicket release cycle.
For example, if a user sees a org.wicketstuff:someproject artifact with a version of 1.4.16.1 they can know immediately that it is based on wicket 1.4.16 and that it is the first point release (the 1.4.16 version would have been the original release).
So you need Wicket 1.5 - or find a version of autocomplete based on 1.4.17.