I'm trying to upgrade myfaces to latest version (without the whole java EE 8 stack, since tomee 8 is still not released).
It seems to work fine in most of the cases, however refreshing some pages throws this error
java.lang.ClassCastException: [B cannot be cast to java.base/java.lang.Integer
at org.omnifaces.util.Hacks.removeViewState(Hacks.java:432)
at org.omnifaces.viewhandler.OmniViewHandler.unloadView(OmniViewHandler.java:134)
at org.omnifaces.viewhandler.OmniViewHandler.restoreView(OmniViewHandler.java:101)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:97)
Please note that this is not a bug report, it's just a question. Should omnifaces 2.x work with jsf 2.3?
This is caused by unload of a page associated with OmniFaces #ViewScoped. This is supposed to work just fine. This issue also manifests in OmniFaces 3.0. It has as per issue 444 been fixed in OmniFaces 2.6.9 and 3.1.
Related
After months of working fine, my primary test iModel no longer appears to be accessible. Was working with iModel API 2.3, but, even after upgrading to 2.18 and switching over to BriefCaseManager.downloadBriefCase, I still can't fetch the BriefCase. The error I recieve: Error |imodelhub-client.iMdoelHub| 501 iModelHup.FeatureIsDisabled: Feature is disabled.
Any insights on what I can do to get past this? I'm not seeing any options in PlantSight to enable/disable features that might be related to this
2.18.0 version contains the fixes which address the FeatureIsDisabled error. Could you please verify that you've built your project with 2.18 version?
Caused by: java.lang.IllegalStateException: Unable to complete the scan for annotations for web application [] due to a StackOverflowError. Possible root causes include a too low setting for -Xss and illegal cyclic inheritance dependencies. The class hierarchy being processed was [org.bouncycastle.asn1.ASN1EncodableVector->org.bouncycastle.asn1.DEREncodableVector->org.bouncycastle.asn1.ASN1EncodableVector]
at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(ContextConfig.java:2104)
at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2048)
at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1994)
at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1964)
at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1917)
...
I am new to the Spring framework.
Here is the error message. Sometimes it can run while after stopping the project and re-run it, these messages are shown (but if I leave the IDE along for 5-10 mins, it can be run without errors).
What exactly is happening here? I am using the newest IDEA and Tomcat 8.
Solved. The reason is I was using a different version of Tomcat, version 8, while somehow the code is using version 7.
I am using macOS Mojave. On Windows, the code can be run via different versions, however, it seems that on macOS the version matters.
First I installed 9.0.1 FP2 IF1 on the server (901FP2HF384_W64) and I was told that this would make dojo 1.9.4 the default dojo, but it was not. I needed to add xsp.client.script.dojo.version=1.9.4 to my XSP Property file to get it to work
Next I need dojo 1.9.4 on the client as well, both as xpinc and when doing preview in web browser so I installed first FP2 IF1 (901FP2SHF63_W32_standard) and later on also FP2 IF3 (901FP2SHF63_W32_standard) but none of these fixes seem to have added dojo 1.9.4
I did try to add xsp.client.script.dojo.version=1.9.4 to my application but I get the following error in both xpinc and preview in web-browser
No Dojo library found matching the configured Dojo library version xsp.client.script.dojo.version=1.9.4.
I ran the following code in a repeat...
com.ibm.xsp.context.DojoLibraryFactory.getDefaultLibrary().getVersion()
...and found out the following
Dojo installed using Preview in webbrowser
1.8.3
1.5.2
1.8.3
1.5.2
Dojo Installed using xpinc
1.9.2
1.5.2
1.9.2
1.5.2
What am I doing wrong here, Why is the fixes not installing 1.9.4? and how can I get 1.9.4 (same as on server) without installing separate dojo packages
Related
http://www-01.ibm.com/support/docview.wss?uid=swg21686751
On the first issue, you should definitely not need the xsp property to apply dojo 1.9.4, it should be the default. We have not come across any issue with this, thus I'm not sure what the problem is that you are experiencing. Perhaps try uninstalling & reinstalling the IF and/or FP2 and/or both?
On the Notes client issues: The 9.0.1 FP2 Interim Fix 1 fixed an iOS8 issue on the server (for XPages mobile controls) by upgrading dojo to 1.9.4 - http://www-01.ibm.com/support/docview.wss?uid=swg21657963#Domino
At present there is no Interim Fix that upgrades the dojo version on the Client - http://www-01.ibm.com/support/docview.wss?uid=swg21657963#Notes. There is no use case involving the use of XPages Mobile controls in the client, so the dojo version in the client was left untouched. It was actually unprecedented to upgrade dojo in an Interim Fix, but the severity of the iOS8 issue meant it needed to be done on the server.
You could manually copy the "com.ibm.xsp.dojo" folder from the server over to your Notes install to have 1.9.4 on both server and client
I am attempting to start Apache Geronimo using the command:
./bin/geronimo run
When I do this, it spins for a minute, issues the message "Main not found" and exits.
This article suggests that it is a system resource issue:
http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5551-Failing-to-start-the-server-with-the-error-quot-Main-not-found-quot-td1324013.html
I have tried it on both an Amazon EC2 box (running Linux), and an Azure A1 box (running Windows Server), and I have tried the "Full Profile Release" and "Web Profile Release" of Geronimo, all with no change.
I'm at a complete loss as to what I could try. I am led to believe that the EC2 box, at the very least, should have the muscle to run Geronimo.
Any suggestions would be welcome.
Version 3 of Apache Geronimo is designed to run on JRE 1.7 instead of JRE 1.8. As stated in the other answers, the issue was caused by Geronimo being run on JRE 1.7 instead of 1.8.
You are not limited to JRE 1.7 and earlier in order to run Geronimo though. Therefore, all you have to do is to rename or copy the property jre-1.7 in the file etc/config.properties in your installation to jre-1.8. Afterwards, you should be able to run Geronimo without an error.
This has a huge benefit, since now you will be able to run programs on Geronimo that use Java 8 features.
It turns out that the issue is that I had the wrong version of the JDK installed. I had installed the most recent version (8), but Geronimo apparently won't work with that. When I instead installed version 6, everything worked fine.
I was getting the same error with Java 8. I tried the latest version of Java SE 7 and that resolved the problem. So I wouldn't use Java 6, since it is and has been out of support for awhile now (read: security issue).
Restlet 2.1.RC1 works fine but upgrading to 2.1.2 gives :
WARN - Unable to unmarshal the XML representation
javax.xml.bind.JAXBException: Unable to create customized SAX source
- with linked exception:
[javax.xml.parsers.ParserConfigurationException: FEATURE_SECURE_PROCESSING: Cannot set the feature to false when security manager is present.]
at org.restlet.ext.jaxb.internal.Unmarshaller.unmarshal(Unmarshaller.java:201)
at org.restlet.ext.jaxb.JaxbRepresentation.getObject(JaxbRepresentation.java:417)
at org.restlet.ext.jaxb.JaxbConverter.toObject(JaxbConverter.java:172)
at org.restlet.service.ConverterService.toObject(ConverterService.java:170)
at org.restlet.resource.Resource.toObject(Resource.java:828)
at org.restlet.engine.resource.ClientInvocationHandler.invoke(ClientInvocationHandler.java:240)
at com.sun.proxy.$Proxy57.getServerInformation(Unknown Source)
I confess a while ago I posted a very similar question - but in that one I focused on the issue that
Restlet 2.1.2 + Java 1.6 as a Netbeans 7.x app works.
But changing java to Java 1.7 gives above error so I think this question is not a duplicate as here I am focusing on Restlet 2.1.RC1 ==> 2.1.2.
As mention in other question I suspect this change is related.
The eventual workaround was the code hack described in
https://stackoverflow.com/a/19230016/449347
See the bug raised at https://github.com/restlet/restlet-framework-java/issues/785