Good day ladies and gentlemen, i've upgraded my kohana from 3.1.x to a latest 3.3.x version and now im getting an error:
ErrorException [ Fatal Error ]: Class 'Model_register' not found
Can somebody help me?
Follow the upgrade guides for 3.1.x => 3.2.x and 3.2.x => 3.3.x.
With 3.2.x Kohana changed the naming conventions to be PSR-0 compliant. That means if a class called Kohana_Core is currently located in classes/kohana/core.php you have to change it to classes/Kohana/Core.php. You will have to either upgrade all your modules to the current versions, or fix the naming yourself (which could be a lot of work).
The issue you are seeing is most likely related to the change of the naming conventions. If it isn't, what is the module that caues this error?
Related
I'm trying to compile a Salesforce sfdx plugin which is a node project with (among others) the following dependency chain that ultimately leads to fake-timers#^7.1.0:
#salesforce/command#2.2.0 -> #oclif/test#^1.2.4 -> fancy-test#^1.4.3 -> #types/sinon#* -> #sinonjs/fake-timers#^7.1.0.
When compiling it with the Typescript compiler tsc, I get the following error:
node_modules/#sinonjs/fake-timers/types/fake-timers-src.d.ts:11:28 - error TS2304: Cannot find name 'queueMicrotask'.
11 queueMicrotask: typeof queueMicrotask;
~~~~~~~~~~~~~~
Found 1 error.
error Command failed with exit code 1.
This looks like a bug in fake-timers-src.d.ts but introduced in 7.1.0 so I could try to lock the version at 7.0.5 but that might break all kinds of other things.
Does anybody who uses/maintains fake-timers know how to fix this? Or will this be fixed in a future version?
BTW I'm a total NodeJS n00b so if there's something really obvious here that I'm missing, please be kind and just tell me what it is :)
Thanks!
Frans
Frans! fatso83 from the Sinon team here :)
The problem here has all to do with TypeScript and nothing to do with Node, so I feel your pain. No wonder you are wondering. The problem is that the definitions are probably missing that property. For version 7 we tried to generate TypeScript definitions from JSDoc. This works reasonably well for simpler type, but ultimately, TypeScript is more powerful in describing types than JSDoc (like the typeof operator), so it was an uphill battle that would never result in the same quality as the types available from the external Definitely Typed project. We ended up abandoning that effort and therefore this will not be fixed, but it will naturally go away with version 8 (that will not be shipping its own types).
What you can do is this: npm install #sinonjs/fake-timers#6 (which is the previous version) and npm install #types/sinonjs__fake-timers#6 (which are the externally maintained types).
You might find some background for this in this issue.
I have an OR problem and using an academic version of cplex library in the jupyter notebook by python 3.6.
When I am calling the following command I get an error:
command:
solution=mdl.solve(log_output=True)
error:
TypeError: can't pickle dict_keys objects
when I removed (log_output=True) everything works just fine, but I need the detailed output.
Since this is a crossed reference question, I would rather not repeat myself and confuse other people. The reason to ask here is that different scholars are attending these two reference webpages.
https://github.com/IBMDecisionOptimization/docplex-examples/issues/14
If I find my answer in stackoverflow I will share the solution procedure here and on github.
From the solution found in the external link: the problem is fixed in docplex ersion 2.10.150. Upgrading to that version fixes the problem.
As Daniel Junglas mentioned there were some inconsistencies between the two version of docplex toolbox and cplex 12.9 academic version I was using. A member of IBM team noticed the problem and updated the docplex version. And the lastest version up to date 07/08/2019 is here https://pypi.org/project/docplex/2.10.150/.
Many thanks to IBM Team.
Heloo, I have this error:
Fatal error: Class CI_Session_files_driver contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (SessionHandlerInterface::open, SessionHandlerInterface::read) in D:\wamp64\www\has\system\libraries\Session\drivers\Session_files_driver.php on line 49
I have tried proposed solutions from forums and I have replaced the system folder of CI 3 but still no luck. Restarting apache fixes the problem temporary. But after a while, it still comes back. Here is my working environment:
Windows 10 64 bit Pro; Wamp Server 3.1.0; PHP Version 7.1.10; Codeigniter 3.1.6;
What is very interesting, i have two other projects on this Wamp Server that are on Codeigniter 2, and they dont seem to have this problem. I noticed this when i switched from PHP5 to PHP7. Any ideas or thoughts?
Some one reported similar issue on Github:
PHP >= 7 session problem,
which link to the solution, turn off opcache in php.ini:
opcache.enable=0
Hope this is the solution you are looking for, currently I don't have the setup to reproduce the error.
Class CI_Session_files_driver contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (SessionHandlerInterface::open, SessionHandlerInterface::close) using Codeigniter
The one of the reason for this error is recursive function calling with no ending.
I believe this problem not to be related to module exclusions in JDK 9 (as with java.se.ee), but rather with the fact that JDK 9 includes a newer version of org.w3c.dom.ls in the java.xml module that does not have the DocumentLS class.
The important bit of the stack trace is this:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [spring-test/test-container.xml]; nested exception is java.lang.NoClassDefFoundError: org/w3c/dom/ls/DocumentLS
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181)
Even if I include a runtime dependency with this class, like xerces:xerces 2.4.0, the JDK java.xml module is preferred (I guess).
I am using Gradle 4.1. Is there any way to restrict the scope of a
JDK provided module?
As you have correctly analyzed, the package org.w3c.dom.ls is present in the platform module java.xml. Any class on the class path that is in the same package will be ignored. That's called a split package and several fixes exist - the following two might help you.
Patch java.xml
You can add the classes of the Xerxes JAR to the java.xml module with --patch-module:
java --patch-module java.xml=xerxes-4.0.0.jar ...
I've never tried that with a JAR that contains some of the same classes. As I understand it, the JDK classes will then be replaced with the Xerxes classes, which means they better be a fully binary compatible replacement.
Upgrade java.xml
Another hope is to replace java.xml with the upgrade module path:
The upgrade module path (--upgrade-module-path) contains compiled definitions of modules intended to be used in place of upgradeable modules built-in to the environment (compile time and run time).
You face two problems:
the upgrade module path is supposed to be used only for upgradable modules (which java.xml is not), but I think I've read somewhere that that's not enforced (yet?) - didn't try it
the artifact you replace java.xml with needs to be fully binary compatible update - would that be the case for Xerxes?
From what I can tell, DocumentLS is from a 2002 draft of the W3C API, it doesn't appear to have made it into a released version. It looks like xerces-2.4.0 (from 2006?) includes it but newer versions don't. So upgrading to a more recent Xerces may be needed here. If Spring really depends on DocumentLS then it will need to be updated too.
I am trying to generate Excel using Xssf API because its memory footprint is small.
It is working fine in my local machine which is having jdk1.7.
But when I try to run it on UNIX where java version is 1.6.0_75 it gives me the following error.
java.lang.NoClassDefFoundError: Could not initialize class org.apache.poi.openxml4j.opc.internal.marshallers.ZipPackagePropertiesMarshaller
I have following jars in my classpath
poi-3.11-20141221.jar
poi-excelant-3.11-20141221.jar
poi-ooxml-3.11-20141221.jar
poi-ooxml-schemas-3.11-20141221.jar
xmlbeans-2.6.0.jar
xercesImpl.jar
I have verified that poi-3.11-20141221.jar has the ZipPackagePropertiesMarshaller class.
Seems that some jar is missing.
Am I missing something?
I have found a solution to my own problem.
I replaced poi-3.11-20141221.jar with poi-ooxml-3.9.jar. That worked.
Java version 1.6.0_75 does not exists, I suppose you make a typo. The last update of Java 6 is the update 45 (6u45).
The class ZipPackagePropertiesMarshaller is loaded at run-time for sure. The exception NoClassDefFoundError occurs during the initialization phase; if the exception had been ClassNotFoundException, it would have been different...
The class ZipPackagePropertiesMarshaller is unaltered between the versions 3.11 and 3.9, but the class PackagePropertiesMarshaller extended by ZipPackagePropertiesMarshaller is changed: the main change regards the use of StAX in the newer version.
The distribution of StAX coming with Java 6, but the version of Java 6 update 18 (http://www.oracle.com/technetwork/java/javase/6u18-142093.html) introduces the StAX 1.2 API version.
Consider to use Java 6u18 or newer. This should solve your problem.
In the official FAQ there are some indications about a similar problem: https://poi.apache.org/faq.html#faq-N1017E.
Moreover, the workaround you found is not the best one, see the last FAQ of POI.