instead of specifying --add-opens java.base/java.util=ALL-UNNAMED to allow reflection to java.util package at jvm startup, is there an option to allow it for all packages i.e. --add-opens all/all=ALL-UNNAMED ?
Related
We get an error when resolving our swift package:
error: packageC is required using two different revision-based requirements (feature1 and development), which is not supported
Our dependency tree looks like:
Package A
├ Package B
│ └ Package C
└ Package C
In the Package.swift manifest of PackageA we have a dependency to PackageC's branch feature1.
In the Package.swift manifest of PackageB we also have a dependency to PackageC. But this time to branch development.
The Question:
Is there a way to have all PackageC's use the specified branch in specified in PackageA's manifest? (Besides manually specifying it in all the dependencies manifests)
I got around the problem by setting environment variables that all the manifest reads their required branch names from.
ProcessInfo.processInfo.environment["package_branch"]
I am attempting to execute a program which uses qt qml on rockchip Linux. I have just added Qt5Charts to the runtime environment. On execution i get :
[W] MyApp - QQmlApplicationEngine failed to load component
[W] MyApp - qrc:/qml/main.qml:103 Type MediaViewerScene unavailable
qrc:/qml/MediaScene.qml:3 module "QtCharts" version 5.9 is not installed
I have in /usr/lib:
libQtCharts5, libQtCharts5.9, libQtCharts5.9.1
and in /usr/qml/QtCharts:
designer plugins.qmltypes
libqtchartsqml2.so qmldir
I think I may have not adb pushed a required file.
This is /usr/qml/QtCharts/designer/default]# ls
AreaSeries.qml PieSeries.qml
BarSeries.qml PolarAreaSeries.qml
BoxPlotSeries.qml PolarLineSeries.qml
HorizontalBarSeries.qml PolarScatterSeries.qml
HorizontalPercentBarSeries.qml PolarSplineSeries.qml
HorizontalStackedBarSeries.qml ScatterSeries.qml
LineSeries.qml SplineSeries.qml
PercentBarSeries.qml StackedBarSeries.qml
Thanks for any help.
I have a trouble with LSF alljoyn 15.04, I build LSF in ubuntu 16.04 success but I cannot run any app. I'm receiving Notification whenever I run the ./lighting_controller_client_sample in service_framework-15.04/core/service_framework/build/linux/standard_core_library/lighting_controller_client/samples:
./lighting_controller_client_sample: symbol lookup error:
./lighting_controller_client_sample: undefined symbol:
_ZN3ajn15_RemoteEndpoint17PushMessageRouterERN3qcc10ManagedObjINS_8_MessageEEERm
How can I fix it?
Sounds like it can't find cpp libs (the .a and .so files).
In which case you need to define LD_LIBRARY_PATH.
For example, if you are building alljoyn with scons, then define the following environment variable before running your sample.
export LD_LIBRARY_PATH=/core/alljoyn/build/linux/x86_64/release/dist/cpp/lib
or
export LD_LIBRARY_PATH=/core/alljoyn/build/linux/x86_64/debug/dist/cpp/lib
That will at least allow it to find the alljoyn cpp lib files.
While trying to call an EJB made using NETbeans (using jdk1.7) from a client made using Eclipse IDE (using jdk1.6), I am getting following error-
Exception in thread "main" java.lang.UnsupportedClassVersionError: stateless/TestEjbRemote : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at com.sun.ejb.EJBUtils.getBusinessIntfClassLoader(EJBUtils.java:688)
at com.sun.ejb.EJBUtils.loadGeneratedRemoteBusinessClasses(EJBUtils.java:463)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:414)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:556)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:514)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at Main.main(Main.java:19)
Any solution to this problem ?
Try to change the Target JRE version to 1.6 in Build Configuration.
Problem was- I was calling EJB,made using jdk1.7 from client, which was using jdk1.6. Switched the jdk1.7 to jdk 1.6, it worked. or one can switch jdk1.6 to 1.7, then also it would work.
Conclusion- u can call any EJB which is using either the same version or lower version of jdk as the caller.
I had the same problem but I was using textpad though. The solution was pretty simple. Try placing the class in conflict on a different location (a backup folder perhaps whatever) or you can just simply delete it as long as it doesn't exist on the same directory. Then try compiling the java file so you can have a new class built to your computer's specification. Try if it works for you coz it worked for me. :)
It's the second time I've had the issue, just change the build configuration of this project.
Right click your project name --> [properties] --> [java compiler] --> [Enable project specific settings] --> set [compiler compliance level] to 1.7
Eclipse has it's own compiler, no matter which version of javac(jdk) in you system,so you must configure the version of eclipse compiler firstly.
Reference: java.lang.UnsupportedClassVersionError: Bad version number in .class file?
On some of our servers collective.monkeypatch does not work:
Unable to detect Zope version. Please make sure you have Zope 2.10.4 or newer installed.
2011-03-24 10:17:13 ERROR collective.monkeypatcher Could not patch because version not recognized. Wanted: [2, 13, 9], Installed: []
2011-03-24 10:17:13 INFO collective.monkeypatcher Preconditions for patching scope <class 'z3c.form.form.BaseForm'> not met (Zope2-=2.13.999)!
2011-03-24 10:17:13 ERROR collective.monkeypatcher Could not patch because version not recognized. Wanted: [2, 13, 9], Installed: []
2011-03-24 10:17:13 INFO collective.monkeypatcher Preconditions for patching scope <class 'z3c.form.group.GroupForm'> not met (Zope2-=2.13.999)!
We have tried the some buildout on different computers and cannot come up with reliable pattern why it is failing (probably something egg and version pindown related)
What could be the issue and how to
The Unable to detect Zope version. Please make sure you have Zope 2.10.4 or newer installed. comes from older Plone versions (version 3.0 and earlier, it was removed in the 3.1 line). It uses the old-style App.version_txt.getZopeVersion API to read a version.txt file from the Zope2 module directory, but that is not always written. I do not see it in my Zope2 installs installed with the plone.recipe.zope2install recipe in any case. This log message is otherwise harmless provided you do use Zope 2.10.4 or newer.
With the advent of a proper Zope2 egg, Plone now uses the pkg_resources module to make this test and in Zope 2.12 the getZopeVersion API uses pkg_resources internally as well. The collective.monkeypatcher precondition test also uses pkg_resources to introspect package versions.
From your Unable to detect Zope version log entry I infer that you are using an older Plone version (3.0 or older) and thus you are most likely using Zope 2.10. Zope 2.10 is not an egg, so there is no egg metadata for pkg_resources to get a version from. Thus the version test fails for any Zope version before 2.12.
The obvious work-around is to not use the package defining the monkeypatch on Zope servers older than 2.12. But you can also generate a fake egg with the version information included with the plone.recipe.zope2install recipe:
[zope2]
recipe = plone.recipe.zope2install
...
additional-fake-eggs =
Zope2 = 2.10.11
Fake eggs provide enough metadata for pkg_resources to get a version number, but the zope2install recipe writes a default Zope2 fake egg with a 0.0 version. By defining the fake egg with a version number you end up with pkg_resources giving you enough information to satisfy the precondition. You may have to upgrade your plone.recipe.zope2install version, I see some refactoring and bug-fixes have been applied to the way fake eggs are generated that may affect you.
I think the problem is in the preconditions attribute of your monkeypatch directive.
See documentation at http://pypi.python.org/pypi/collective.monkeypatcher