Hi Mark,

Checked deeper the sample and seems it is the old lambda issue, so indeed
we can avoid the NPE and fallback on Object but since it was not done I'm
not sure it would be helpful compared to current code.
Here is the test:

@Test
public void testLambda() {
    final MessageHandler.Whole<String> handler = message -> {
    };
    Assert.assertEquals(Object.class, Util.getMessageType(handler));
}

So guess we can play the status-quo.

Side note: seems ide-intellij ant task got broken with java 22 API usage of
the source.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 22 janv. 2024 à 12:53, Mark Thomas <ma...@apache.org> a écrit :

> On 21/01/2024 18:33, Romain Manni-Bucau wrote:
> > Hi,
> >
> > I know websocket 1.0 methods without providing the handler type are kind
> of
> > deprecated (not recommended would be more correct) so not sure this bug
> > would get a fix or not.
> > Long story
> > short,
> org.apache.tomcat.websocket.WsSession#addMessageHandler(jakarta.websocket.MessageHandler)
> > will call Util.getMessageType which goes into the reflection code and the
> > interesting part is org.apache.tomcat.websocket.Util#getGenericType and
> > more precisely TypeResult superClassTypeResult = getGenericType(type,
> > superClazz); which can return null (end of recursion) but next line
> being int
> > dimension = superClassTypeResult.getDimension(); we can get a NPE.
> >
> > The fix is trivial but I'mnot sure it is worth it or just redirecting to
> > the right API would be better.
>
> It depends whether this is one of the cases we can actually handle
> correctly or if it is one where you have to use the new API.
>
> If we can handle it correctly, we should. If not, I'm fine with throwing
> an although it looks like the error handling might need a small tweak in
> that case.
>
> Can you provide a concrete example that currently fails?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Reply via email to