We have have an application using the java 3D API.
I know that java 3D will try to use whichever 3D rendering engine is available on the machine.
Is there an API that will detect whether a client machine is capable of using the entire java 3D API ?
Example: recently we got the stacktrace below from a client using A Windows 8 tablet with Java Web Start 10.25.2.16, Using JRE version 1.7.0_25-b16 Java HotSpot(TM) Client VM.
Exception occurred in RenderingErrorListener:java.lang.NullPointerException
at sun.awt.SunToolkit.getSystemEventQueueImplPP(Unknown Source)
at sun.awt.SunToolkit.getSystemEventQueueImplPP(Unknown Source)
at sun.awt.SunToolkit.getSystemEventQueueImpl(Unknown Source)
at java.awt.Toolkit.getEventQueue(Unknown Source)
at java.awt.EventQueue.invokeLater(Unknown Source)
at javax.swing.SwingUtilities.invokeLater(Unknown Source)
We implemented javax.media.j3d.RenderingError and got the message below:
OFF_SCREEN_BUFFER_ERROR: Renderer: Error creating Canvas3D off-screen buffer
graphicsDevice = Win32GraphicsDevice[screen=0]
Is there a way to get more details about the error ?
Is there any way to debug the rendering engine discovery/selection ?
The WebStart version in Java 7u25 stores the sun.awt.AppContext no longer on the system thread group. It stores the AppContext on the main thread.
Therefore threads belonging to a thread group the main thread group is not a parent or grandparent of has no AppContext.
see also: NullPointerException in invokeLater while running through Java Webstart
Related
I am currently trying to enable remote inspector for a OpenJFX web view component in order to be able to debug javascript code interactions with the Java part of the application. This is why I cannot debug the web part in a standalone browser.
There appears to be no detailed documentation related to remote inspector besides a few fixed scenarios which have pre-configured solutions available. Based on reverse-engineering and other research, I was able to piece together the following:
I have obtained an instance of Debugger interface out of the OpenJFX WebEngine instance;
I have created a simple TCP server which communicates with the WebKit browser using its protocol (eg. messages like "SetupInspectorClient", "GetTargetList", "SendMessageToBackend", etc.). This is enough to make the remote WebKit browser recognize my view when opening the inspector://localhost:<port> URI;
When attempting to connect to a particular view, the majority of the communication is handled by the "SendMessageToBackend" and "SendMessageToFrontend" messages forwarded by my code between remote WebKit browser and the Debugger instance. However, based on communication traces the only response that the remote browser receives to its requests is a "'Target' domain was not found" and "'Browser' domain was not found" errors.
I presume the above problem may be caused by either incompatible webkit versions between OpenJFX and my remote browser - although I am using WebKit 613.1 on both ends. Other possibility is that the OpenJFX uses some sort of stripped-down WebKit which does not support the inspector commands at all. However, I don't know enough about WebKit to be able to find it out on my own.
Is it possible to get remote inspector working in OpenJFX 17, and if yes, then how?
We recently upgraded our Windows 10 test environment with ChromeDriver v87.0.4280.20 and Chrome v87.0.4280.66 (Official Build) (64-bit) and after the up-gradation even the minimal program is producing this ERROR log:
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
Minimum Code Block:
from selenium import webdriver
options = webdriver.ChromeOptions()
options.add_argument("start-maximized")
driver = webdriver.Chrome(options=options, executable_path=r'C:\WebDrivers\chromedriver.exe')
driver.get('https://www.google.com/')
Console Output:
DevTools listening on ws://127.0.0.1:64170/devtools/browser/2fb4bb93-79ab-4131-9e4a-3b65c08dbffb
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
[9848:10684:1201/013233.172:ERROR:device_event_log_impl.cc(211)] [01:32:33.173] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
Anyone facing the same? Was there any change in ChromeDriver/Chrome v87 with respect to ChromeDriver/Chrome v86?
Any clues will be helpful.
However these log messages can be supressed from appearing on the console through an easy hack i.e. by adding an argument through add_experimental_option() as follows:
options.add_experimental_option('excludeSwitches', ['enable-logging'])
Code Block:
from selenium import webdriver
options = webdriver.ChromeOptions()
options.add_argument("start-maximized")
# to supress the error messages/logs
options.add_experimental_option('excludeSwitches', ['enable-logging'])
driver = webdriver.Chrome(options=options, executable_path=r'C:\WebDrivers\chromedriver.exe')
driver.get('https://www.google.com/')
My apologies for the log spam. If you aren't having issues connecting to a device with WebUSB you can ignore these warnings. They are triggered by Chrome attempting to read properties of USB devices that are currently suspended.
After going through quite a few discussions, documentations and Chromium issues here are the details related to the surfacing of the log message:
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
Details
It all started with the reporting of chromium issue Remove WebUSB's dependency on libusb on Windows as:
For Linux (probably Mac as well), both WebUSB notification and communication works correctly (after allowing user access to the device in udev rules).
For Windows, it seems that libusb only works with a non-standard WinUsb driver (https://github.com/libusb/libusb/issues/255).
When the hardware is inserted and the VID/PID is unknown to the system, windows 10 correctly loads it's CDC driver for the CDC part and the WinUSB driver (version 10) for the WebUSB part (no red flags). However, it seems that chrome never finds the device until I manually force an older WinUSB driver (version 6 - probably modified also) on the interface.
The solution was implemented in a step-wise manner as follows:
Start supporting some transfers in the new Windows USB backend
Fix bulk/interrupt transfers in the new Windows USB backend
[usb] Read BOS descriptors from the hub driver on Windows
[usb] Collect all composite devices paths during enumeration on Windows
[usb] Remove out parameters in UsbServiceWin helper functions
[usb] Support composite devices in the new Windows backend
[usb] Detect USB functions as Windows enumerates them
[usb] Support composite devices with multiple functions
[usb] Hold interface requests until Windows enumerates functions
[usb] Add direction parameter to ClearHalt
[usb] Count references to a WINUSB_INTERFACE_HANDLE
[usb] Implement blocking operations in the Windows backend
These changes ensured that the new backend was ready to be tested and was available through Chrome Canary and chrome-dev-channel which you can access manually through:
chrome://flags#enable-new-usb-backend
More change requests were submitted as follows:
[usb] Mark calls to SetupDiGetDeviceProperty as potentially blocking: According to hang reports this function performs an RPC call which may take some time to complete. Mark calls with a base::ScopedBlockingCall so that the thread pool knows this task may be busy for a while.
variations: Enable NewUsbBackend in field trial testing config: This flag was experimental as beta-channel uses this change configuration as the default for testing.
As the experimental launch of the new backend appeared to be stable, finally these configuration was enabled by default so that the chanege rolls out to all users of Chrome 87 through usb: Enable new Windows USB backend by default. Revision / Commit
The idea was once this configuration becomes the default for a few milestones, Chromium Team will start removing the Windows-specific code from the old back-end and remove the flag.
Road Ahead
Chromium Team have already merged the revision/commit to Extend new-usb-backend flag expiration within Chrome v90 which will be available soon.
Update
As per #ReillyGrant's [Committer, WebDriver for Google Chrome] comment :
..." it would be good to reduce the log level for these messages so they don't appear on the console by default but we haven't landed code to do that yet"...
References
You can find a couple of relevant detailed discussions in:
Failed to read descriptor from node connection: A device attached to the system is not functioning error using ChromeDriver Selenium on Windows OS
Failed to read descriptor from node connection: A device attached to the system is not functioning error using ChromeDriver Chrome through Selenium
I encounered this problem yesterday,and I has fixed it by update all available windows update.
https://support.microsoft.com/en-us/windows/what-to-try-if-your-touchscreen-doesn-t-work-f159b366-b3ef-99ad-24a4-31a4c62ab46d
A partial solution that worked for me
I was getting this error too. It was stopping my program running.
I unplugged all my USB devices, ran the program, with no error.
Plugged the devices back in, ran the program. I am still getting the error, however, the program finished without the error stopping the program.
Note: For WebdriverIO on Windows 10, this suppresses the error messages for me:
"goog:chromeOptions": { "excludeSwitches": ["enable-logging"] }
Where does the functionality of the Selenium lie?
I've read somewhere that the language binding or API provides glue code to use Selenium in java.
Glue code or Binding code: The code that connects incompatible software components.
Jason Huggings wrote JavaScriptTestRunner to control the browser. The functionality to control the browser lie in the JavaScriptTestRunner.
It suffers from Same-origin policy. Paul Hammant created HTTP Proxy to bypass the Same-origin policy. This opened the doors to write tests in multiple languages. We are provided with an API to write tests.
Then WebDriver is created. WebDriver and RC are merged to form Selenium 2.
Where does the functionality to control the browser gone to?
Within the API?
Within the browser driver?
Why does the API is called as glue code or binding code? What does it bind?
Selenium in the general usage of the term is a library - a collection of code organized in modules and packages. In this form it's a WebDriver client - it can communicate with that kind of server, following the WebDriver protocol; thus enabling a programmer to control a browser.
Where does the functionality to control the browser gone to?
In the WebDriver protocol, and the server that translates the WebDriver commands to browser instructions, and back.
Selenium being a client gives you the ability to use this functionality, in your chosen language - conveniently, without you having to learn or directly run WebDriver requests and parse their response.
Why does the API is called as glue code or binding code? What does it bind?
In programming binding is the uniform / or well-defined API of a library, that connects lower-level code (other programs, or the OS) or protocols - WebDriver in this case, to higher-level concepts - your code. Wikipedia to the rescue, with more details.
Glue Code
Glue Code is the executable code most often the source code that serves the purpose of adapting different parts of code that would otherwise be incompatible. Glue code does not contribute any functionality towards meeting any program requirements as such. Instead, it often appears in code that lets the existing libraries or programs to interoperate among themselves, as in language bindings or foreign function interfaces. Glue code may be written in the same language as the code it is gluing together, or in a separate glue language. Glue code is very efficient in rapid prototyping environments where several components are quickly put together into a single language or framework.
JavaScriptTestRunner
Jason Huggins while testing an internal application at ThoughtWorks reduced the time which was required to manually step through the same tests with every change he made developing a Javascript library that could drive the interactions with the webpage which allowed him to automatically rerun tests against multiple browsers. He named this program as the JavaScriptTestRunner. Later, he made JavaScriptTestRunner open source. This library eventually became Selenium Core which underlies all the functionality of Selenium Remote Control (RC) and Selenium IDE.
Unfortunately, to work within the Same Origin Policy, Selenium Core must be placed in the same origin as the Application Under Test (AUT). So another ThoughtWork engineer, Paul Hammant, created a server that would act as an HTTP proxy masking the AUT under a fictional URL, embedding Selenium Core and the set of tests and delivering them as if they were coming from the same origin. This system became known as the Selenium Remote Control (Selenium RC), or Selenium 1.
Why to use HTTP proxy
Again, when web frameworks were becoming more complex and powerful, the restrictions of Web Browsers’ sandboxed Javascript environment were increasingly limiting the effectiveness of Selenium Core. Simon wanted a testing tool that spoke directly to the browser using the "native" method for the browser and operating system, thus avoiding the restrictions of a sandboxed Javascript environment. That was when WebDriver and Selenium RC were merged to form Selenium 2. All implementations of WebDriver that communicate with web browsers started using a common wire protocol. This wire protocol defined the RESTful web service using JSON over HTTP.
Conclusion
In short, the functionality to control the browser was always within the Javascript library that driven the interactions with the webpage which was part of the JavaScriptTestRunner and later Selenium Core.
As per the diagram below with respect to the different classes/interfaces the functionality to control the browser is with the selenium-api
Worklight 6.2.0
Native Worklight App on Samsung Galaxy S4, Android 4.4.2
WLAnalytics.enable();
WLAnalytics.log("some text", new org.json.JSONOBject() );
WLAnalytics.send();
// and also go on to successfully call an adapter
Analytics Dasboard shows the app version and adapter activity. Log Search does not show any application log messages and the dropdown for selecting applications shows "All Applications" only, no sign of my app.
Have I missed some initialisation step? Any other ideas?
** edited to add **
It has been suggested that we should use the method:
WLAnalytics.log("some text");
In our 6.2.0.00 CLI environment there is no such Java method.
The answer is that there a further initialisation requirement that seems to be necessary when working with a pure Native application, these are typically build using the Worklight CLI tooling.
This is the initialisation, note the call to Logger.setContext()
WLAnalytics.enable();
Logger.setContext(this);
Then this works
WLAnalytics.log("My test message2", new org.json.JSONObject());
It's worth noting that the call to WLAnalytics.send() is not necessary in normal running as typically the analytic data is buffered and sent as a piggy-back on adapter calls. However while testing a call to send() does help.
Further, if running in an environment where the Analytics WAR is on a separate machine from the Worklight Server WAR there are additional latencies. Hence testing all of this needs care.
For now, I suggest that you just use the WLAnalytics.log(String) method. There are some clear inconsistencies that need to be dealt with whether it be through documentation or code fixes.
The WL.Logger APIs were originally created to send log data to a custom adapter, which is why they take a dictionary/object for extra metadata. The data sent to the custom adapter could be read as a valid JSON object to run operations on the adapter.
The WL.Analytics APIs mimicked the WL.Logger APIs for the same purpose: parsing the JSON on a worklight adapter. The Operational analytics server came as a convenience to intercept and display some of these logs, but not all of them are being captured as you have learned.
Your questions are all valid though, as none of this is described in the documentation. In future releases, we may make use of the extra JSON object passed into the API in the Operational analytics console, but for right now they only serve their original purpose of sending the analytics to a custom adapter.
Is any way to capture video from usb camera with javafx or other way with java except jmf?
Right now, javafx.scene.media provides playback support only.
From the documentation -
public Media(java.lang.String source)
Constructs a Media instance. This is the only way to specify the media
source. The source must represent a valid URI and is immutable. Only
HTTP, FILE, and JAR URLs are supported. If the provided URL is invalid
then an exception will be thrown.
http://docs.oracle.com/javafx/2/media/simpleplayer.htm
http://docs.oracle.com/javafx/2/api/javafx/scene/media/package-summary.html