You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2024/01/21 18:33:48 UTC
[bug] websocket generics?
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.
Side note: for the context i'm using records instead of pojo, not very
important since I guess interfaces would lead to the same issues but makes
it more concrete.
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>
Re: [bug] websocket generics?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
For the IDE issue, how do you setup the build in eclipse, didnt java
version reference in eclipse files?
using java 21 + --enable-preview fails due to allocateFrom() usage (java
22) but using java 22 EA fails cause both setups are not compatible it
seems.
Alternatively, moving panama integration to another module until it is
final wouldnt be bad IMHO, in particular while no LTS supports the required
code and it still moves, no?
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 à 20:58, Mark Thomas <ma...@apache.org> a écrit :
>
>
> On 22/01/2024 15:04, Romain Manni-Bucau wrote:
> > 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.
>
> To save others doing the search:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=65458
>
> +1 to leaving things as they are.
>
> > Side note: seems ide-intellij ant task got broken with java 22 API usage
> of
> > the source.
>
> Possibly. I'm an Eclipse user so we'll need an IntelliJ user to take a
> look at that.
>
> Mark
>
>
> >
> > 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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [bug] websocket generics?
Posted by Mark Thomas <ma...@apache.org>.
On 22/01/2024 15:04, Romain Manni-Bucau wrote:
> 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.
To save others doing the search:
https://bz.apache.org/bugzilla/show_bug.cgi?id=65458
+1 to leaving things as they are.
> Side note: seems ide-intellij ant task got broken with java 22 API usage of
> the source.
Possibly. I'm an Eclipse user so we'll need an IntelliJ user to take a
look at that.
Mark
>
> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [bug] websocket generics?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [bug] websocket generics?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org