You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@guacamole.apache.org by Mark Nolan <ma...@gmail.com> on 2019/06/17 02:02:08 UTC
Auth Provider from 0.9.14 does not work with 1.0.0
I have an authentication provider that was working perfectly with 0.9.14.
I have updated it to work with 1.0.0, but have got stuck and need some
suggestions.
I can see everything loading. I can see my UserContext being returned and
my Resource as well. I know they are not null. However, no endpoint methods
of the resource are ever called and I get the following error:
02:53:32.840 [http-nio-8080-exec-2] ERROR o.a.g.rest.RESTExceptionMapper -
Unexpected internal error: null for uri:
http://localhost:8080/guacamole-1.0.0/api/session/ext/XXX/hello?token=0F854D6F2B13FA69E3C43E0FBDEA0759316BD93329DCB152CB53B732413D461C
02:53:32.841 [http-nio-8080-exec-2] DEBUG o.a.g.rest.RESTExceptionMapper -
Unexpected error in REST endpoint.
com.sun.jersey.api.NotFoundException: null for uri:
http://localhost:8080/guacamole-1.0.0/api/session/ext/XXX/hello?token=0F854D6F2B13FA69E3C43E0FBDEA0759316BD93329DCB152CB53B732413D461C
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1512)
[jersey-server-1.17.1.jar:1.17.1]
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
[jersey-server-1.17.1.jar:1.17.1]
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
[jersey-server-1.17.1.jar:1.17.1]
(more available on request!)
Where I have replaced the authentication provider name with XXX. The hello
endpoint is just something I threw in for testing, but (again) it works
perfectly with 0.9.14.
If someone knows what changed in 1.0.0 that could have caused this, that
would be great! Otherwise, what I really need are some ideas of what to
look at next.
Thanks,
Mark.
.
Re: Auth Provider from 0.9.14 does not work with 1.0.0
Posted by Mark Nolan <ma...@gmail.com>.
Probably don't need Jersey. Will have some time to investigate now. I just
knew that if I took that version, it would be compatible, rather than
having to hunt through and work out which version to use. ;)
M.
.
On Tue, 18 Jun 2019 at 19:57, Mike Jumper <mj...@apache.org> wrote:
> On Tue, Jun 18, 2019 at 10:30 AM Mark Nolan <ma...@gmail.com> wrote:
>
> > There were no other errors at all!
> >
> > For a moment I was very excited that I might have forgotten to update
> that
> > dependency, but I hadn't been that stupid (wouldn't have been the first
> > time!). I didn't know whether to be relieved or frustrated!
> >
> > Anyway, I created a minimal version and went through it all bit by bit.
> The
> > problem was that I had another version of the JAX-RS api in the pom:
> >
> > <dependency>
> > <groupId>org.glassfish.jersey.media</groupId>
> > <artifactId>jersey-media-json-jackson</artifactId>
> > <version>2.27</version>
> > </dependency>
> >
> > Need this to get a much more up to date version of Jackson and,
> > conveniently, it also allowed the JAX-RS annotations to compile.
> >
>
> As it's the Guacamole webapp that will be using the base parts of Jersey,
> this may be causing trouble.
>
>
> >
> > This worked fine in 0.9.14, but not in 1.0.0. Not really sure why that
> > should have changed.
> >
>
> My guess would be that including this previously had no effect, with your
> extension actually using the classes exposed by the webapp. Part of the
> changes for 1.0.0 included giving extensions priority for classes on the
> classpath, allowing extensions to use different versions of classes
> internally even if the webapp uses the same library. That may not work as
> expected for something like Jersey.
>
> See:
> http://guacamole.apache.org/releases/1.0.0/#improvements-to-extension-api
> ("... Dependency
> precedence has been updated so that extensions always see the classes they
> bundle, even if the web application bundles a different version of the same
> class. ...")
>
> Are you sure you need to include Jersey in your dependencies? I've normally
> used the following to make JAX-RS annotations available within an extension
> and let the webapp handle the rest:
>
> <dependency>
> <groupId>javax.ws.rs</groupId>
> <artifactId>jsr311-api</artifactId>
> <version>1.1.1</version>
> <scope>provided</scope>
> </dependency>
>
> - Mike
>
Re: Auth Provider from 0.9.14 does not work with 1.0.0
Posted by Mike Jumper <mj...@apache.org>.
On Tue, Jun 18, 2019 at 10:30 AM Mark Nolan <ma...@gmail.com> wrote:
> There were no other errors at all!
>
> For a moment I was very excited that I might have forgotten to update that
> dependency, but I hadn't been that stupid (wouldn't have been the first
> time!). I didn't know whether to be relieved or frustrated!
>
> Anyway, I created a minimal version and went through it all bit by bit. The
> problem was that I had another version of the JAX-RS api in the pom:
>
> <dependency>
> <groupId>org.glassfish.jersey.media</groupId>
> <artifactId>jersey-media-json-jackson</artifactId>
> <version>2.27</version>
> </dependency>
>
> Need this to get a much more up to date version of Jackson and,
> conveniently, it also allowed the JAX-RS annotations to compile.
>
As it's the Guacamole webapp that will be using the base parts of Jersey,
this may be causing trouble.
>
> This worked fine in 0.9.14, but not in 1.0.0. Not really sure why that
> should have changed.
>
My guess would be that including this previously had no effect, with your
extension actually using the classes exposed by the webapp. Part of the
changes for 1.0.0 included giving extensions priority for classes on the
classpath, allowing extensions to use different versions of classes
internally even if the webapp uses the same library. That may not work as
expected for something like Jersey.
See:
http://guacamole.apache.org/releases/1.0.0/#improvements-to-extension-api
("... Dependency
precedence has been updated so that extensions always see the classes they
bundle, even if the web application bundles a different version of the same
class. ...")
Are you sure you need to include Jersey in your dependencies? I've normally
used the following to make JAX-RS annotations available within an extension
and let the webapp handle the rest:
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>jsr311-api</artifactId>
<version>1.1.1</version>
<scope>provided</scope>
</dependency>
- Mike
Re: Auth Provider from 0.9.14 does not work with 1.0.0
Posted by Mark Nolan <ma...@gmail.com>.
There were no other errors at all!
For a moment I was very excited that I might have forgotten to update that
dependency, but I hadn't been that stupid (wouldn't have been the first
time!). I didn't know whether to be relieved or frustrated!
Anyway, I created a minimal version and went through it all bit by bit. The
problem was that I had another version of the JAX-RS api in the pom:
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>2.27</version>
</dependency>
Need this to get a much more up to date version of Jackson and,
conveniently, it also allowed the JAX-RS annotations to compile.
This worked fine in 0.9.14, but not in 1.0.0. Not really sure why that
should have changed.
I have changed it to the rather tedious:
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>1.17.1</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>javax.xml.stream</groupId>
<artifactId>stax-api</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-core-asl</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-jaxrs</artifactId>
</exclusion>
<exclusion>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-xc</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.module</groupId>
<artifactId>jackson-module-jaxb-annotations</artifactId>
</dependency>
With the Jackson BOM included to get the more recent version.
It is possible that I don't need all those exclusions because the namespace
appears to have changed. When I resolve all my other issues, I'll take a
look at that.
Thanks,
Mark.
.
On Mon, 17 Jun 2019 at 21:44, Mike Jumper <mj...@apache.org> wrote:
> On Sun, Jun 16, 2019 at 7:02 PM Mark Nolan <ma...@gmail.com> wrote:
>
> > I have an authentication provider that was working perfectly with 0.9.14.
> >
> > I have updated it to work with 1.0.0, but have got stuck and need some
> > suggestions.
> >
> > I can see everything loading. I can see my UserContext being returned and
> > my Resource as well. I know they are not null. However, no endpoint
> methods
> > of the resource are ever called and I get the following error:
> >
> > 02:53:32.840 [http-nio-8080-exec-2] ERROR o.a.g.rest.RESTExceptionMapper
> -
> > Unexpected internal error: null for uri:
> >
> >
> http://localhost:8080/guacamole-1.0.0/api/session/ext/XXX/hello?token=0F854D6F2B13FA69E3C43E0FBDEA0759316BD93329DCB152CB53B732413D461C
> > 02:53:32.841 [http-nio-8080-exec-2] DEBUG o.a.g.rest.RESTExceptionMapper
> -
> > Unexpected error in REST endpoint.
> > com.sun.jersey.api.NotFoundException: null for uri:
> >
> >
> http://localhost:8080/guacamole-1.0.0/api/session/ext/XXX/hello?token=0F854D6F2B13FA69E3C43E0FBDEA0759316BD93329DCB152CB53B732413D461C
> > at
> >
> >
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1512)
> > [jersey-server-1.17.1.jar:1.17.1]
> > at
> >
> >
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
> > [jersey-server-1.17.1.jar:1.17.1]
> > at
> >
> >
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
> > [jersey-server-1.17.1.jar:1.17.1]
> >
> > (more available on request!)
> >
> > Where I have replaced the authentication provider name with XXX. The
> hello
> > endpoint is just something I threw in for testing, but (again) it works
> > perfectly with 0.9.14.
> >
>
> Are there any other errors earlier in the logs?
>
> Did you update your extension to use the 1.0.0 version of guacamole-ext?
>
> If someone knows what changed in 1.0.0 that could have caused this, that
> > would be great! Otherwise, what I really need are some ideas of what to
> > look at next.
>
>
> I've not seen that specific error before and am not sure what would cause
> it, however the overall changes to the extension API for 1.0.0 are in the
> release notes:
>
> http://guacamole.apache.org/releases/1.0.0/#extension-api-changes
>
> When updating the Java parts of an extension from release X to release Y,
> you generally should only need to update the guacamole-ext dependency to
> match release Y and fix any build errors that result, referencing the
> release notes and guacamole-ext API docs as you go.
>
> - Mike
>
Re: Auth Provider from 0.9.14 does not work with 1.0.0
Posted by Mike Jumper <mj...@apache.org>.
On Sun, Jun 16, 2019 at 7:02 PM Mark Nolan <ma...@gmail.com> wrote:
> I have an authentication provider that was working perfectly with 0.9.14.
>
> I have updated it to work with 1.0.0, but have got stuck and need some
> suggestions.
>
> I can see everything loading. I can see my UserContext being returned and
> my Resource as well. I know they are not null. However, no endpoint methods
> of the resource are ever called and I get the following error:
>
> 02:53:32.840 [http-nio-8080-exec-2] ERROR o.a.g.rest.RESTExceptionMapper -
> Unexpected internal error: null for uri:
>
> http://localhost:8080/guacamole-1.0.0/api/session/ext/XXX/hello?token=0F854D6F2B13FA69E3C43E0FBDEA0759316BD93329DCB152CB53B732413D461C
> 02:53:32.841 [http-nio-8080-exec-2] DEBUG o.a.g.rest.RESTExceptionMapper -
> Unexpected error in REST endpoint.
> com.sun.jersey.api.NotFoundException: null for uri:
>
> http://localhost:8080/guacamole-1.0.0/api/session/ext/XXX/hello?token=0F854D6F2B13FA69E3C43E0FBDEA0759316BD93329DCB152CB53B732413D461C
> at
>
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1512)
> [jersey-server-1.17.1.jar:1.17.1]
> at
>
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442)
> [jersey-server-1.17.1.jar:1.17.1]
> at
>
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391)
> [jersey-server-1.17.1.jar:1.17.1]
>
> (more available on request!)
>
> Where I have replaced the authentication provider name with XXX. The hello
> endpoint is just something I threw in for testing, but (again) it works
> perfectly with 0.9.14.
>
Are there any other errors earlier in the logs?
Did you update your extension to use the 1.0.0 version of guacamole-ext?
If someone knows what changed in 1.0.0 that could have caused this, that
> would be great! Otherwise, what I really need are some ideas of what to
> look at next.
I've not seen that specific error before and am not sure what would cause
it, however the overall changes to the extension API for 1.0.0 are in the
release notes:
http://guacamole.apache.org/releases/1.0.0/#extension-api-changes
When updating the Java parts of an extension from release X to release Y,
you generally should only need to update the guacamole-ext dependency to
match release Y and fix any build errors that result, referencing the
release notes and guacamole-ext API docs as you go.
- Mike