I installed Views module for Drupal 6 and tried to create a view with a Page display but I can't save or preview it. All I can see are these warnings:
strict warning: Declaration of views_plugin_style_default::options() should be compatible with views_object::options() in C:\My\Site\Path\test6\sites\all\modules\views\plugins\views_plugin_style_default.inc on line 13.
strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in C:\My\Site\Path\test6\sites\all\modules\views\plugins\views_plugin_row.inc on line 24.
strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in C:\My\Site\Path\test6\sites\all\modules\views\plugins\views_plugin_row.inc on line 24.
strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in C:\My\Site\Path\test6\sites\all\modules\views\handlers\views_handler_filter.inc on line 26.
strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in C:\My\Site\Path\test6\sites\all\modules\views\handlers\views_handler_filter.inc on line 26.
strict warning: Declaration of views_handler_filter_term_node_tid::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in C:\My\Site\Path\test6\sites\all\modules\views\modules\taxonomy\views_handler_filter_term_node_tid.inc on line 6.
Can you please check your browser for availability of Jquery when your drupal site pages load. Specially your views pages. What version of Jquery is your Drupal site using. I have faced this before and was sorted out by first ensuring availability of correct compatible version of jquery.
This might have happened if you tried to update your Jquery version through Jquery_update module. Can you please check it and reply accordingly. I am sure this is very much solvable.
Related
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'm using a chef community cookbook that downloads, installs, a configures an SDK. (Let's call it the blah-sdk.) You just include_recipe 'blah-sdk' and viola, it's installed. It has an attribute specifying the version of the blah-sdk it will install. This version attribute in turn is used to form the value of a corresponding 'download_url' attribute. In theory I should be able to set the value of version attribute to something else in the cookbook where I include the blah-sdk. But there is a problem. The download_url attribute gets set (using the default version specified in the blah-sdk cookbook) before my override version attribute does. So the wrong url is used to retrieve the default version rather than the version I want. I could set the download_url in my cookbook as well, but that breaks the encapsulation of the 'blah-sdk' cookbook. I also might end up playing whack-a-mole experimentally with some long stream of attributes before getting it to work. There has got to be a better way. What is it?
cookbooks/blah-sdk/attributes/default.rb:
default['blah']['version'] = '24.4'
default['blah']['download_url'] = "http://dl.company.com/blah/blah-sdk_r#{node['blah']['version']}-linux.tgz"
cookbooks/blah-sdk/recipes/default.rb:
...
print("blah version: #{node['blah']['version']}")
print("blah download_url: #{node['blah']['download_url']}")
...
cookbooks/my_cookbook/attributes/default.rb:
normal['blah']['version'] = '24.4.1'
(I've also tried using default, force_default, override, and force_override. Made no difference.)
cookbooks/my_cookbook/recipes/default.rb
...
include_recipe 'blah-sdk'
...
Output:
==> default: blah version: 24.4.1
==> default: blah download_url: http://dl.company.com/blah/blah-sdk_r24.4-linux.tgz
Code demonstrating the issue and coderanger's suggested solution (if you can fix the third party cookbook):
https://github.com/marc-swingler/stackoverflow_question
Not the best solution, but due to the order in which attributes are loaded, dropping the version into a role or environment works too.
https://christinemdraper.wordpress.com/2014/10/06/avoiding-the-possible-pitfalls-of-derived-attributes/
See https://coderanger.net/derived-attributes/ for an overview of this problem. There is no good solution that doesn't involve modifying the upstream cookbook. Easiest solution is to duplicate the derived attribute in your wrapper as well.
My application has minSdk at 15 and targetSdk at 20. I need a support library because my application uses the PageViewer view.
Reading the documentation I read that the support library vx is designed to be used on the API level x. I think that the version's number x should be between 15 and 20.
How should I choose that number?
Secondly, using android studio I have to add the following line in a file named build.grandle, for using the support library v4.
compile 'com.android.support:support-v4:20.0.0'
What is the meaning of the suffix 20.0.0?
The support libraries have different revisions/versions. You can check more info here
Adding this part in your gradle file:
compile 'com.android.support:support-v4:20.0.0'
you are telling gradle to get the support-library-v4 with revision 20.0.0.
About which version you should use. If you compiling with api20, you can use the revision 20.
Per JAXB specification http://jaxb.java.net/2.2.4/docs/xjc.html if you want to run the JAXB-XJC compiler, one of the of the extensions/arguments you may pass is -Xpropertyaccessors even though it has been specfied in each of JAXB-RI till the latest one 2.2.5u2 still when I try to run it passing this argument I get 'unrecognized parameter -Xpropertyaccessors' is not specified in the help menu when I run it. It is important for me to have the access levels on properties not fields.
I have followed up with the JAXB RI lead, apparently the plugin is there but not enabled. The issue will be fixed in versions 2.1.14 and 2.2.6 of the JAXB RI. I would recommend entering a bug so that you will be able to track the status of the issue.
http://java.net/jira/browse/JAXB/
According to MSDN, there is version attribute but if you specify a wrong version number VC still compiles the code. For example:
// MSO.DLL (Microsoft Office, Object Library)
// Office 10.0 => version(2.2)
// Office 11.0 => version(2.3)
// Office 12.0 => version(2.4)
#import "libid:2DF8D04C-5BFA-101B-BDE5-00AA0044DE52" version(123.456) //< wrong version.
How to force the compiler to fail on such code? I would like to use only specific version of type-library.
You can't. The rules are explained in LoadRegTypeLib:
LoadRegTypeLib compares the requested version numbers against those
found in the system registry, and takes one of the following actions:
If one of the registered libraries exactly matches both the
requested major and minor version numbers, then that type library is
loaded.
If one or more registered type libraries exactly match the
requested major version number, and has a greater minor version number
than that requested, the one with the greatest minor version number is
loaded.
If none of the registered type libraries exactly match the
requested major version number (or if none of those that do exactly
match the major version number also have a minor version number
greater than or equal to the requested minor version number), then
LoadRegTypeLib returns an error.
Your case matches the 2nd bullet, not the 3rd. Microsoft does spend a lot of effort on making these type libraries backward compatible. Not taking advantage of it is easy to do. Build your project on a machine with the right type library. Copy the generated .tlh and .tli files to your project directory and check them in. Replace the #import with #includes for those files.