[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Mark Thomas --- Fixed in: - 10.0.x for 10.0.6 onwards - 9.0.x for 9.0.46 onwards - 8.5.x for 8.5.66 onwards -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #8 from Mark Thomas --- I've applied a fix for Endpoints to 10.0.x, 9.0.x and 8.5.x. I'll look at Encoders and Decoders next so if there are any issues with the current approach do let me know. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #7 from romain.manni-bucau --- @Mark functionally I can leave with current validation but theorically the validation is only known of the IoC but it is not super aligned on the spec. To illustrate it take a CDI or Spring encoder, it can use constructor injections and not have a default no-arg constrauctor but spec requires it so I guess validation can be let this way and we can ask the spec to drop this later moving the validation to the instantiation time only. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #6 from Mark Thomas --- @Rémy I think I can see a way to do that. We'll need to check which Configurator was used in the WsSession constructor to make sure we don't call the InstanceManager twice. It does mean that the timing of the call to InstanceManager will vary depending on the Configurator but I don't think that should be an issue. @Romain Do you need the InstanceManager to used used when testing the validity of the encoder/decoder classes (e.g. https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/websocket/Util.java#L345) or just when an Encoder/Decoder instance is created for an Endpoint? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #5 from Remy Maucherat --- (In reply to romain.manni-bucau from comment #4) > @Mark: this issue is about the default configurator, fully agree when a > custom configurator is used tomcat will not care. I agree if using the default configurator then we know what it does and instead of complying 100% with the specification, we could shortcut to the instance manager to create the instance and solve your problem. There are shortcuts for IO as well, so why not. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #4 from romain.manni-bucau --- @Mark: this issue is about the default configurator, fully agree when a custom configurator is used tomcat will not care. I also agree encoders/decoders IoC support is not in the specification but not having it lead to very weird patterns - even for just a plain JSON codec when you want to do it right and consistent with app code/config, makes it not natural at all and lead to easy leaks so I think it is worth going through the InstanceManager anyway and make it to the spec at some point. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #3 from Mark Thomas --- Section 3.1.7 of the WebSocket specification requires endpoint instances are created via ServerEndpointConfig.Configurator.getEndpointInstance(). Users are free to supply their own Configurator implementation. Therefore, it is not possible to use the InstanceManager to create the endpoint. The current call to InstanceManager.newInstance(Object) is the best that can be achieved. I'll spend a little more time looking at the encoders and decoders but, given that there is no specification requirement for these to support DI, whether anything gets implemented is going to depend a lot on how cleanly it can be done. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #2 from romain.manni-bucau --- Hmm, endpoint api starts from a class on server side so should use the related instance manager instantiator and not only the injection "newInstance" probably. For an annotated endpoint you likely inject PojoEndpoint since the bean is not an endpoint which is not that useful. I'd also like encoders/decoders to comply to the IoC/instance manager otherwise no way to get a bound resource like a mapper. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65262] Enable websocket endpoints to be IoC friendly (javaee integration at least)
https://bz.apache.org/bugzilla/show_bug.cgi?id=65262 --- Comment #1 from Mark Thomas --- WebSocket endpoints already use the InstanceManager. https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/websocket/WsSession.java#L180 https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/websocket/WsSession.java#L548 Is the request to have the InstanceManager create the endpoint instances from the class name rather than use InstanceManager.newInstance(Object) ? Using the InstanceManager for Encoders and Decoders looks to be rather more complex. I looked at the spec but I didn't see a requirement for this 7.1.1 only discusses WebSocket endpoint classes. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
