ppalaga commented on PR #2237: URL: https://github.com/apache/cxf/pull/2237#issuecomment-2621149723
> Thanks a lot @ppalaga, but I believe this change could be considered a breaking one (please correct me if I am wrong): the previously generated classes would end up under different package. This could be disruptive, Yes, you are right, the generated classes now end up in a different package. The classification of the change depends a bit from how CXF defines its public API. While I'd personally tend to see this as an implementation detail not exposed to CXF users, you may know of use cases where users rely on the package name. I'd let you decide because I do not think I am experienced enough with CXF. Another aspect is whether this is actually a bug in plain CXF. When writing the test, I found out that the issue is not happening in stock CXF where only `WrapperClassGenerator` is active. That one is using per service class loaders and it is thus able to provide multiple wrapper classes with the same FQ name. The issue only happens when there is a `GeneratedClassClassLoaderCapture` storing the classes per class name and a `WrapperClassLoader` using them and loading in flat class loader. That's the way we do it in Quarkus CXF. But still, the issue is reproducible on plain CXF using solely CXF classes in a way they were (I believe) designed for. So as long as this issue could be seen as a CXF bug, we perhaps may apply measures "breaking" some internal details. > what do you think if we introduce the package generation extension (SimplePackageNameGenerator, the default / PerSeiPackageNameGenerator) so it would be picked from the Bus? Thanks for the idea! That would certainly solve the problem. I'd be fine going that way, although, in the long term having less configuration knobs is better for maintenance and testing. Wouldn't suffice to introduce the extension only if there comes somebody really needing the old behavior? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
