[
https://issues.apache.org/jira/browse/GUACAMOLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391793#comment-17391793
]
Christopher Speck commented on GUACAMOLE-168:
---------------------------------------------
{{error: package javax.xml.bind does not exist}}
This is one of those packages I mentioned that got removed in Java 11, see
https://stackoverflow.com/questions/52502189/java-11-package-javax-xml-bind-does-not-exist
To allow compiling and running with Java 11 a new dependency will need to be
added.
https://search.maven.org/artifact/jakarta.xml.bind/jakarta.xml.bind-api
Note however that there might be some compatibility issues and instead this
version may be needed
https://search.maven.org/artifact/com.sun.xml.bind/jaxb-impl
If you must compile and run with Java 11 then you will need to update this.
Otherwise I recommend sticking to Java 8 if possible, as updating to Java 11
will likely require additional further updates/issues like this.
> Add support for X.Org
> ---------------------
>
> Key: GUACAMOLE-168
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-168
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client, guacamole-server
> Reporter: Mike Jumper
> Assignee: Mike Jumper
> Priority: Major
> Attachments: 00-guac.conf, Xorg.0.log, err.txt, mvn_error.txt
>
>
> It's been frequently requested that we add support for a more efficient
> protocol like NX or X2Go. Though that sounds nice on the surface, and
> theoretically would allow us to leverage some of Guacamole's nicer
> protocol-level features, investigating deeper reveals:
> # X2Go *is* NX - it uses the same protocol behind the scenes.
> # NX isn't really a protocol - it is essentially a compressor for X11, and
> depends on the client having a local X11 server to handle the decompressed
> result.
> Implementing support for either of these would thus involve implementing
> support for X11, which is crazy. *However:*
> What about implementing a driver for the X.Org X11 server?
> The X.Org server provides a driver abstraction layer which exposes access to
> windows (including their hierarchy) and pixmaps, much in the same way the
> Guacamole protocol provides nestable layers and buffers. If we were to
> implement a Guacamole driver for X.Org, we would be able to make much greater
> use Guacamole protocol features like client-side compositing. Operations
> which are typically expensive in VNC or RDP like window movement suddenly
> become simple, as they only involve updating the properties of a layer.
> I have an experimental implementation of all this, built upon several other
> improvements which ended up being required. Work started several years ago,
> even before Guacamole was accepted into the Apache Incubator, but I think
> it's finally ready to move forward. I've been using it myself for roughly a
> month now, and so far so good.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
