You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@guacamole.apache.org by Nick Couchman <vn...@apache.org> on 2018/05/28 19:00:31 UTC
Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Hey, everyone,
I could use some help figuring out how to work this one out. GUACAMOLE-566
deals with adding the RESTExceptionWrapper to loaded extensions such that
the extension-specific REST endpoints will deliver similar Guacamole error
messages rather than just causing a generic Tomcat Error 500. Basically
this means adding an interceptor to the classes such that any of those
REST-specific methods get passed through the exception wrapper. I've tried
a couple of different routes and am not having much success. The first one
I tried was this:
https://github.com/necouchman/guacamole-client/blob/22e8fe2b7638a7ab53e957af234c67b5cadc116e/guacamole/src/main/java/org/apache/guacamole/extension/Extension.java#L393-L409
Basically I tried creating an injector, using AbstractModule, and binding
the Interceptor to the class and getting that instance of the class. This
didn't work at all - the extensions wouldn't even load and there were
several errors in the Tomcat localhost log file. Then, I went this route:
https://github.com/necouchman/guacamole-client/blob/5f3d82a542d2abab4844314d1df83c1262f89083/guacamole/src/main/java/org/apache/guacamole/extension/Extension.java#L583-L589
Making the Extension class extend the AbstractModule class and overriding
configure, and adding the interception, there. And, while this continues
to allow the classes to load, it doesn't actually seem to be intercepting
any of the REST calls - I still just get the same generic Tomcat Error 500
without the interception.
Any pointers on where to go from here - what needs to be intercepted, and
where?
Thanks,
Nick
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Mike Jumper <mi...@glyptodon.org>.
On Tue, May 29, 2018 at 12:07 PM, Nick Couchman <vn...@apache.org> wrote:
> On Tue, May 29, 2018 at 2:59 PM, Nick Couchman <vn...@apache.org> wrote:
>
> > >
> >> >
> >> Perhaps the mapper needs to be bound, just like the webapp's REST
> >> services?
> >>
> >> https://stackoverflow.com/questions/11987097/how-do-i-
> >> use-a-jersey-exceptionmapper-with-google-guice
> >>
> >
> >
> > Yep, that seems to be the ticket to getting it to work. So, next
> > question, should this be registered only with the ExtensionModule and
> > RESTServiceModule classes, or should it also be added to the TunnelModule
> > classes? I can see some definite advantages of also having this in the
> > tunnel modules (I'm thinking of one of the routes we talked about for
> > parameter prompting), but not sure if that will cause other issues?
> >
> > -Nick
> >
>
> Also, does it make sense, instead of implementing this in addition to the
> current RESTExceptionWrapper, to try to just tweak the APIException class
> and have everything go through this? Seems like maybe this could
> completely replace the current method of injecting the RESTExceptionWrapper
> and just catch and handle all of the GuacamoleExceptions that are
> generated?
>
It's definitely worth a shot. If this exception mapper accomplishes
everything the RESTExceptionWrapper tried to do with method interceptors,
then that's great.
There is some magic within RESTExceptionWrapper which automatically
identifies whether a session token was involved with the request and
invalidates that token if GuacamoleUnauthorizedException, etc. are thrown.
If that functionality can be handled within the exception mapper, then
there really isn't any reason for RESTExceptionWrapper to stick around. If
not, then we can at least get rid of the part of RESTExceptionWrapper which
maps the exceptions to JSON, and rely on it solely for invalidating tokens.
- Mike
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Nick Couchman <vn...@apache.org>.
On Tue, May 29, 2018 at 2:59 PM, Nick Couchman <vn...@apache.org> wrote:
> >
>> >
>> Perhaps the mapper needs to be bound, just like the webapp's REST
>> services?
>>
>> https://stackoverflow.com/questions/11987097/how-do-i-
>> use-a-jersey-exceptionmapper-with-google-guice
>>
>
>
> Yep, that seems to be the ticket to getting it to work. So, next
> question, should this be registered only with the ExtensionModule and
> RESTServiceModule classes, or should it also be added to the TunnelModule
> classes? I can see some definite advantages of also having this in the
> tunnel modules (I'm thinking of one of the routes we talked about for
> parameter prompting), but not sure if that will cause other issues?
>
> -Nick
>
Also, does it make sense, instead of implementing this in addition to the
current RESTExceptionWrapper, to try to just tweak the APIException class
and have everything go through this? Seems like maybe this could
completely replace the current method of injecting the RESTExceptionWrapper
and just catch and handle all of the GuacamoleExceptions that are generated?
-Nick
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Nick Couchman <vn...@apache.org>.
On Tue, May 29, 2018 at 3:19 PM, Mike Jumper <mi...@glyptodon.org>
wrote:
> On Tue, May 29, 2018 at 11:59 AM, Nick Couchman <vn...@apache.org> wrote:
>
> > >
> > > >
> > > >
> > > Perhaps the mapper needs to be bound, just like the webapp's REST
> > services?
> > >
> > > https://stackoverflow.com/questions/11987097/how-do-i-
> > > use-a-jersey-exceptionmapper-with-google-guice
> > >
> >
> >
> > Yep, that seems to be the ticket to getting it to work. So, next
> question,
> > should this be registered only with the ExtensionModule and
> > RESTServiceModule classes, or should it also be added to the TunnelModule
> > classes? I can see some definite advantages of also having this in the
> > tunnel modules (I'm thinking of one of the routes we talked about for
> > parameter prompting), but not sure if that will cause other issues?
> >
> >
> Is registration that selective?
>
> I'd expect that bind()'ing the wrapper within RESTServiceModule would be
> all that's necessary, and then anything which Jersey happens to serve will
> magically handle GuacamoleException as expected.
>
Good point, I'll try it out and see. Maybe just the single registration
there will be all that's needed.
>
> The parts related to TunnelModule are not REST endpoints - they're specific
> to Guacamole's HTTP and WebSocket transport mechanisms. For things like
> parameter prompting, I'd expect those prompts would be out-of-band, the
> result of issuing a request to a REST endpoint which is tunnel-related but
> not actually directly tied to TunnelModule.
>
>
Sounds good, I'll leave those alone.
-Nick
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Mike Jumper <mi...@glyptodon.org>.
On Tue, May 29, 2018 at 11:59 AM, Nick Couchman <vn...@apache.org> wrote:
> >
> > >
> > >
> > Perhaps the mapper needs to be bound, just like the webapp's REST
> services?
> >
> > https://stackoverflow.com/questions/11987097/how-do-i-
> > use-a-jersey-exceptionmapper-with-google-guice
> >
>
>
> Yep, that seems to be the ticket to getting it to work. So, next question,
> should this be registered only with the ExtensionModule and
> RESTServiceModule classes, or should it also be added to the TunnelModule
> classes? I can see some definite advantages of also having this in the
> tunnel modules (I'm thinking of one of the routes we talked about for
> parameter prompting), but not sure if that will cause other issues?
>
>
Is registration that selective?
I'd expect that bind()'ing the wrapper within RESTServiceModule would be
all that's necessary, and then anything which Jersey happens to serve will
magically handle GuacamoleException as expected.
The parts related to TunnelModule are not REST endpoints - they're specific
to Guacamole's HTTP and WebSocket transport mechanisms. For things like
parameter prompting, I'd expect those prompts would be out-of-band, the
result of issuing a request to a REST endpoint which is tunnel-related but
not actually directly tied to TunnelModule.
- Mike
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Nick Couchman <vn...@apache.org>.
>
> >
> >
> Perhaps the mapper needs to be bound, just like the webapp's REST services?
>
> https://stackoverflow.com/questions/11987097/how-do-i-
> use-a-jersey-exceptionmapper-with-google-guice
>
Yep, that seems to be the ticket to getting it to work. So, next question,
should this be registered only with the ExtensionModule and
RESTServiceModule classes, or should it also be added to the TunnelModule
classes? I can see some definite advantages of also having this in the
tunnel modules (I'm thinking of one of the routes we talked about for
parameter prompting), but not sure if that will cause other issues?
-Nick
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Mike Jumper <mi...@glyptodon.org>.
On Tue, May 29, 2018 at 11:02 AM, Nick Couchman <vn...@apache.org> wrote:
> >
> > IIRC, there are minimum JVM version requirements for Jersey 2.x that
> >>
> > historically prevented us from going that route, but if we're going to
> >> require Java 7 across the board, this is doable.
> >>
> >
> > Okay, I'll see what I can figure out with that. Hopefully it won't be
> > necessary to make it work - I've found some examples of people using it
> > with some 1.x versions - but looks like maybe the 1.x versions don't
> > automatically scan for the @Provider tag and pull in the mappers, and
> they
> > may need to be manually registered. Not certain about that, just my
> > working theory at this point.
> >
> >
> After doing some light reading today, it looks like getting Jersey 2.x to
> work with Guice is non-trivial - apparently the Jersey team decided to go a
> slightly different route when writing 2.0, and so there may be some
> significant changes required to get it to play nice. Looks like a few
> folks out there have written some examples and even bridge projects to help
> make the jump, but it still seems to require a decent amount of effort.
>
> Going back to the Jersey 1.x stuff, I've still no clue why the
> ExceptionMapper class isn't loading with the @Provider tag on it. There's
> some indication that you can force registration of it using entries in the
> web.xml file, but, if you go this route, you also have to set the the name
> and class used for the servlet itself, and currently this doesn't appear to
> be used (and I'm not certain if it would actually work??). Something like
> this:
>
> <servlet>
> <servlet-name>guacamole</servlet-name>
> <servlet-class>
> org.apache.guacamole.???
> </servlet-class>
> <init-param>
> <param-name>com.sun.jersey.config.property.packages</param-name>
> <param-value>
> org.apache.guacamole.rest
> </param-value>
> </init-param></servlet>
>
>
> I tried just providing the <init-param></init-param> tags without the
> servlet-name and servlet-class, and it didn't like that too much. The
> other options I can find out there seem to be:
>
I think this configuration parameter will only work if you're using the
Jersey "ServletContainer" servlet for the REST endpoints, but we're using
GuiceFilter, GuiceContainer, etc.
- Providing a class that extends javax.ws.rs.core.ResourceConfig and pull
> in the mapper in there. I'm guessing this ResourceConfig-based class has
> to be referenced somewhere else in the code, too, in order to make it
> actually do something. I don't see anything like that currently
> implemented, so guessing this would be new...
> - Extend the javax.ws.rs.core.Application class, which has some hooks to
> add providers and/or exception mappers more directly. Again, this seems
> like it would be a pretty heavy change to the classes that currently run
> the REST endpoints.
>
> Suggestions on where to go from here?
>
>
Perhaps the mapper needs to be bound, just like the webapp's REST services?
https://stackoverflow.com/questions/11987097/how-do-i-
use-a-jersey-exceptionmapper-with-google-guice
- Mike
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Nick Couchman <vn...@apache.org>.
>
> IIRC, there are minimum JVM version requirements for Jersey 2.x that
>>
> historically prevented us from going that route, but if we're going to
>> require Java 7 across the board, this is doable.
>>
>
> Okay, I'll see what I can figure out with that. Hopefully it won't be
> necessary to make it work - I've found some examples of people using it
> with some 1.x versions - but looks like maybe the 1.x versions don't
> automatically scan for the @Provider tag and pull in the mappers, and they
> may need to be manually registered. Not certain about that, just my
> working theory at this point.
>
>
After doing some light reading today, it looks like getting Jersey 2.x to
work with Guice is non-trivial - apparently the Jersey team decided to go a
slightly different route when writing 2.0, and so there may be some
significant changes required to get it to play nice. Looks like a few
folks out there have written some examples and even bridge projects to help
make the jump, but it still seems to require a decent amount of effort.
Going back to the Jersey 1.x stuff, I've still no clue why the
ExceptionMapper class isn't loading with the @Provider tag on it. There's
some indication that you can force registration of it using entries in the
web.xml file, but, if you go this route, you also have to set the the name
and class used for the servlet itself, and currently this doesn't appear to
be used (and I'm not certain if it would actually work??). Something like
this:
<servlet>
<servlet-name>guacamole</servlet-name>
<servlet-class>
org.apache.guacamole.???
</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>
org.apache.guacamole.rest
</param-value>
</init-param></servlet>
I tried just providing the <init-param></init-param> tags without the
servlet-name and servlet-class, and it didn't like that too much. The
other options I can find out there seem to be:
- Providing a class that extends javax.ws.rs.core.ResourceConfig and pull
in the mapper in there. I'm guessing this ResourceConfig-based class has
to be referenced somewhere else in the code, too, in order to make it
actually do something. I don't see anything like that currently
implemented, so guessing this would be new...
- Extend the javax.ws.rs.core.Application class, which has some hooks to
add providers and/or exception mappers more directly. Again, this seems
like it would be a pretty heavy change to the classes that currently run
the REST endpoints.
Suggestions on where to go from here?
-Nick
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Nick Couchman <vn...@apache.org>.
On Tue, May 29, 2018 at 11:44 AM, Mike Jumper <mi...@guac-dev.org>
wrote:
> On Tue, May 29, 2018, 08:36 Nick Couchman <vn...@apache.org> wrote:
>
> > On Tue, May 29, 2018 at 9:18 AM, Nick Couchman <
> nick.e.couchman@gmail.com>
> > wrote:
> >
> > > On Mon, May 28, 2018 at 11:19 PM, Mark Nolan <ma...@gmail.com>
> wrote:
> > >
> > >> Don't you see those warnings anyway? I can't check right now, but I'm
> > >> fairly certain I've seen them in the log regardless.
> > >>
> > >>
> > > Yeah, Mark, you're right, those show up in a clean build without this,
> so
> > > that's obviously not the issue.
> > >
> > > I added a little more debugging - an empty constructor with a log
> message
> > > - and I don't see that firing, either, so it doesn't look like Jersey
> is
> > > picking this up and injecting it at all. I'll keep digging...
> > >
> >
> > I'm wondering, now, if this has to do with the version of Jersey being
> > used?
>
>
> Are you referring to the custom exception handler apparently not being
> used? Or to the Guice warning you mentioned earlier?
>
Not the Guice warning - that doesn't seem to be the issue. I'm referring
to the (apparent) lack of initialization of the custom exception mapper.
>
> Currently guacamole/pom.xml pulls in version 1.17.1 - maybe this is
> > specific to Jersey 2.x? Anyone know how hard it is to migrate from 1.x
> to
> > 2.x?
> >
>
> IIRC, there are minimum JVM version requirements for Jersey 2.x that
> historically prevented us from going that route, but if we're going to
> require Java 7 across the board, this is doable.
>
Okay, I'll see what I can figure out with that. Hopefully it won't be
necessary to make it work - I've found some examples of people using it
with some 1.x versions - but looks like maybe the 1.x versions don't
automatically scan for the @Provider tag and pull in the mappers, and they
may need to be manually registered. Not certain about that, just my
working theory at this point.
-Nick
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Mike Jumper <mi...@guac-dev.org>.
On Tue, May 29, 2018, 08:36 Nick Couchman <vn...@apache.org> wrote:
> On Tue, May 29, 2018 at 9:18 AM, Nick Couchman <ni...@gmail.com>
> wrote:
>
> > On Mon, May 28, 2018 at 11:19 PM, Mark Nolan <ma...@gmail.com> wrote:
> >
> >> Don't you see those warnings anyway? I can't check right now, but I'm
> >> fairly certain I've seen them in the log regardless.
> >>
> >>
> > Yeah, Mark, you're right, those show up in a clean build without this, so
> > that's obviously not the issue.
> >
> > I added a little more debugging - an empty constructor with a log message
> > - and I don't see that firing, either, so it doesn't look like Jersey is
> > picking this up and injecting it at all. I'll keep digging...
> >
>
> I'm wondering, now, if this has to do with the version of Jersey being
> used?
Are you referring to the custom exception handler apparently not being
used? Or to the Guice warning you mentioned earlier?
Currently guacamole/pom.xml pulls in version 1.17.1 - maybe this is
> specific to Jersey 2.x? Anyone know how hard it is to migrate from 1.x to
> 2.x?
>
IIRC, there are minimum JVM version requirements for Jersey 2.x that
historically prevented us from going that route, but if we're going to
require Java 7 across the board, this is doable.
- Mike
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Nick Couchman <vn...@apache.org>.
On Tue, May 29, 2018 at 9:18 AM, Nick Couchman <ni...@gmail.com>
wrote:
> On Mon, May 28, 2018 at 11:19 PM, Mark Nolan <ma...@gmail.com> wrote:
>
>> Don't you see those warnings anyway? I can't check right now, but I'm
>> fairly certain I've seen them in the log regardless.
>>
>>
> Yeah, Mark, you're right, those show up in a clean build without this, so
> that's obviously not the issue.
>
> I added a little more debugging - an empty constructor with a log message
> - and I don't see that firing, either, so it doesn't look like Jersey is
> picking this up and injecting it at all. I'll keep digging...
>
I'm wondering, now, if this has to do with the version of Jersey being
used? Currently guacamole/pom.xml pulls in version 1.17.1 - maybe this is
specific to Jersey 2.x? Anyone know how hard it is to migrate from 1.x to
2.x?
-Nick
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Nick Couchman <ni...@gmail.com>.
On Mon, May 28, 2018 at 11:19 PM, Mark Nolan <ma...@gmail.com> wrote:
> Don't you see those warnings anyway? I can't check right now, but I'm
> fairly certain I've seen them in the log regardless.
>
>
Yeah, Mark, you're right, those show up in a clean build without this, so
that's obviously not the issue.
I added a little more debugging - an empty constructor with a log message -
and I don't see that firing, either, so it doesn't look like Jersey is
picking this up and injecting it at all. I'll keep digging...
-Nick
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Mark Nolan <ma...@gmail.com>.
Don't you see those warnings anyway? I can't check right now, but I'm
fairly certain I've seen them in the log regardless.
On Tue, 29 May 2018, 04:29 Nick Couchman, <vn...@apache.org> wrote:
> >
> > There may be another way, however. Jersey provides for mapping exceptions
> > to responses:
> >
> > https://stackoverflow.com/questions/15185299/jax-rs-
> > jersey-exceptionmappers-user-defined-exception
> >
> > Perhaps we could define such a mapping for GuacamoleException?
> >
> >
> Okay, I'm game. Took a stab at it and no luck so far. I've implemented an
> ExceptionMapper for GuacamoleException, GuacamoleExceptionMapper, with the
> @Provider annotation and the @Override on the toResponse() method, and it
> doesn't appear to be firing the toResponse() method at all (have logger set
> up, not getting any output). I *assume* that since the exception I'm
> actually throwing, QuickConnectException, is a sub-type of
> GuacamoleException, the ExceptionMapper for GuacamoleException will still
> apply, but maybe I shouldn't assume that? I hope that's the case,
> anyway...
>
> Also, during Guacamole startup I see a lot of the following messages in the
> Tomcat catalina.out file for several different classes:
>
> 21:07:35.225 [localhost-startStop-47] DEBUG
> org.apache.ibatis.logging.LogFactory - Logging initialized using 'class
> org.apache.ibatis.logging.slf4j.Slf4jImpl' adapter.
> 28-May-2018 21:07:35.434 WARNING [localhost-startStop-47]
> com.google.inject.internal.ProxyFactory.<init> Method [public void
>
> org.apache.guacamole.auth.jdbc.connection.ConnectionDirectory.add(org.apache.guacamole.net.auth.Identifiable)
> throws org.apache.guacamole.GuacamoleException] is synthetic and is being
> intercepted by
> [org.mybatis.guice.transactional.TransactionalMethodInterceptor@741a3c51].
> This could indicate a bug. The method may be intercepted twice, or may not
> be intercepted at all.
>
> Looks like maybe the GuacamoleExceptionMapper is clashing with some of the
> Guice stuff??
>
> I'll keep plugging away at it, reading documentation, and Googling, but
> always appreciate any hints.
>
> -Nick
>
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Nick Couchman <vn...@apache.org>.
>
> There may be another way, however. Jersey provides for mapping exceptions
> to responses:
>
> https://stackoverflow.com/questions/15185299/jax-rs-
> jersey-exceptionmappers-user-defined-exception
>
> Perhaps we could define such a mapping for GuacamoleException?
>
>
Okay, I'm game. Took a stab at it and no luck so far. I've implemented an
ExceptionMapper for GuacamoleException, GuacamoleExceptionMapper, with the
@Provider annotation and the @Override on the toResponse() method, and it
doesn't appear to be firing the toResponse() method at all (have logger set
up, not getting any output). I *assume* that since the exception I'm
actually throwing, QuickConnectException, is a sub-type of
GuacamoleException, the ExceptionMapper for GuacamoleException will still
apply, but maybe I shouldn't assume that? I hope that's the case, anyway...
Also, during Guacamole startup I see a lot of the following messages in the
Tomcat catalina.out file for several different classes:
21:07:35.225 [localhost-startStop-47] DEBUG
org.apache.ibatis.logging.LogFactory - Logging initialized using 'class
org.apache.ibatis.logging.slf4j.Slf4jImpl' adapter.
28-May-2018 21:07:35.434 WARNING [localhost-startStop-47]
com.google.inject.internal.ProxyFactory.<init> Method [public void
org.apache.guacamole.auth.jdbc.connection.ConnectionDirectory.add(org.apache.guacamole.net.auth.Identifiable)
throws org.apache.guacamole.GuacamoleException] is synthetic and is being
intercepted by
[org.mybatis.guice.transactional.TransactionalMethodInterceptor@741a3c51].
This could indicate a bug. The method may be intercepted twice, or may not
be intercepted at all.
Looks like maybe the GuacamoleExceptionMapper is clashing with some of the
Guice stuff??
I'll keep plugging away at it, reading documentation, and Googling, but
always appreciate any hints.
-Nick
Re: Help with GUACAMOLE-566: Add RESTExceptionWrapper to Extensions
Posted by Mike Jumper <mi...@glyptodon.org>.
On Mon, May 28, 2018 at 12:00 PM, Nick Couchman <vn...@apache.org> wrote:
> Hey, everyone,
> I could use some help figuring out how to work this one out. GUACAMOLE-566
> deals with adding the RESTExceptionWrapper to loaded extensions such that
> the extension-specific REST endpoints will deliver similar Guacamole error
> messages rather than just causing a generic Tomcat Error 500. Basically
> this means adding an interceptor to the classes such that any of those
> REST-specific methods get passed through the exception wrapper. I've tried
> a couple of different routes and am not having much success. The first one
> I tried was this:
>
> https://github.com/necouchman/guacamole-client/blob/
> 22e8fe2b7638a7ab53e957af234c67b5cadc116e/guacamole/src/main/
> java/org/apache/guacamole/extension/Extension.java#L393-L409
>
> Basically I tried creating an injector, using AbstractModule, and binding
> the Interceptor to the class and getting that instance of the class. This
> didn't work at all - the extensions wouldn't even load and there were
> several errors in the Tomcat localhost log file. Then, I went this route:
>
> https://github.com/necouchman/guacamole-client/blob/
> 5f3d82a542d2abab4844314d1df83c1262f89083/guacamole/src/main/
> java/org/apache/guacamole/extension/Extension.java#L583-L589
>
> Making the Extension class extend the AbstractModule class and overriding
> configure, and adding the interception, there. And, while this continues
> to allow the classes to load, it doesn't actually seem to be intercepting
> any of the REST calls - I still just get the same generic Tomcat Error 500
> without the interception.
>
> Any pointers on where to go from here - what needs to be intercepted, and
> where?
>
>
I think we may need to look into a non-Guice mechanism for this to apply to
Guacamole extensions. Reading up on Guice's method interceptors further,
they depend entirely on the intercepted methods being on classes that are
instantiated by Guice injectors. This won't work unless the REST resources
within extensions are instantiated by Guice (probably not a requirement we
want to add onto the extension API):
https://github.com/google/guice/wiki/AOP#limitations
There may be another way, however. Jersey provides for mapping exceptions
to responses:
https://stackoverflow.com/questions/15185299/jax-rs-jersey-exceptionmappers-user-defined-exception
Perhaps we could define such a mapping for GuacamoleException?
- Mike