SmartGWT Spring 6.x / Jakarta support (JDK 17)

[vivek.more@nuance.com]

Hi Team,
We are currently attempting to upgrade our application from Spring 5.x to Spring 6.x, and running into some roadblocks. Specifically, the upgrade requires Jakarta EE suport with JDK 17, which necessitates changing all imports from javax to jakarta in our projects.
However, SmartGWT 12.1p is causing compilation errors in build due to its use of javax.servlet .* imports in classes like com.isomorphic.servlet.IDACall.

So are there any plans to move SmartGWT to support Jakarta EE and JDK 17.
Additionally, curious if there are any known solutions for resolving the namespace issues we are encountering due to smargwt classes.

[EISENMANN]

Same needs for us. We are deploing on Wildfly. WF 27 drops support for Jakarta API < 9.x (prior to the package renaming from javax. to jakarta.).

Are there any plans to migrate the server-side components to the new Jakarta API for new SmartGWT Versions?

[Isomorphic]

Hi guys,

We are looking at doing this migration and trying to assess which clients that prefer older versions might be affected. A couple of questions:

1. no one has ever mentioned this package import issue before, then both of you posted about it within hours of each other. Are you working on the same team?

2. since you're both clearly using the SmartGWT Server framework, how is Spring involved? We ask because Spring largely makes it simpler to do things that the SmartGWT server automates away entirely (such as generating REST services). So what are you using Spring for - maybe authentication?

[vivek.more@nuance.com]

1. We are not from same team. From our messages it's clearly indicates that we are blocked for our Spring 6 upgrade where as EISENMANN has similar issue for Wildfly.
Not sure why you are not aware of it so far, but this Jakarta EE affecting lots of other widely used frameworks / libs (like jetty, hibernate, tomcat etc.) as well which are already migrated to Jakarta in latest version.

2. Yes, apart from Spring security we also have Spring MVC implementation.

One approach to support both older version vs new jakarta based code is by creating dedicated jakarta based jars, like some other frameworks already implemented.
https://mvnrepository.com/artifact/o...ta-servlet-api
https://mvnrepository.com/artifact/o...e-core-jakarta

[EISENMANN]

Hi, the timing is pure coincidence.

We are deploying the SmartGWT Server as part of Java Enterprise Application on Wildfly Application Server, Spring plays no role in our stack.

We are trying to keep our releases ready for the latest Release of Wildfly to have options when the next critical vulnerability is discovered and have been analyzing the new WF 27 in the past 2 weeks.

The Wildfly Team has decided to approach the Jakarta migration using the big-bang approach. WF 27 supports Jakarta EE 10 only (see https://www.wildfly.org/news/2022/11...nal-Released/#!). Jakarta 9 applications will probably run as long as they do not use deprecated APIs, but are not officially supported.

Java EE and Jakarta EE 8 (pre-rename version) is no longer supported - and they do not work, we have verified it.

We are not very happy with this decision, but it is how it is.

SmartGWT Server is the only blocker in our stack, so it would be great to at least know, if this is something you consider doing and a very rough timeline.

Thank you in advance

[Isomorphic]

Hi guys,

We are looking at the Jarkata package switchover. It looks like the folks working on Java have created yet another needless cross-compatibility nightmare, full of ambiguities and conflicting advice.

However, Vivek, what are you using Spring MVC for? With the SmartGWT, zero lines of code are required as far as connecting your UI to your server - literally zero. In fact you also get an OpenAPI-described REST service for external UI to connect to, also zero lines of code for that.

So what would Spring MVC be doing in this system?

[vivek.more@nuance.com]

We have our project build using Spring framework where we have some pages which gets rendered using SmartGWT library.

Can you please provide some estimates for Jakarta migration in SmarGWT.

[vivek.more@nuance.com]

Hi Team, Any update on this.

[Isomorphic]

Unfortunately, this is another (needless) compatibility nightmare. While many direct dependencies seem straightforward to resolve, in other cases, our dependencies rely on javax.* namespaces (such as Apache Commons libraries, like commons-fileupload).

What specifically is your issue with Spring? As long as you don't use SmartGWT's special integration with Spring, it should be able to run in environments where javax.* APIs are present.

[vivek.more@nuance.com]

One of our use case is, we are subclassing the com.isomorphic.servlet.IDACall servlet and override its processRPCTransaction method to handle built-in SmartClient datasource operations.
And as per stacktrace of IDACall servlet it is using https://smartclient.com/smartgwtee-l...ic-spring.html which is still on 4.3.26.RELEASE causing the issue.

[Isomorphic]

As noted above, if you simply don't use SmartGWT's special Spring support, you should not have an issue with using Spring 6.0 alongside SmartGWT. Specifically, do not use isomorphic_spring.jar.

If, after doing this, you run into some kind of further issue, please let us know what that is.

[Isomorphic]

Further update on this: this is really a giant mess. The main problem is, for every single third-party library we integrate with (Hibernate/JPA, Spring, many others), there are a ton of method parameters being passed that may be either javax.* or jakarata.* namespace.

We cannot simply drop support for all the versions of Java libraries that still use javax namespaces. The vast majority of enterprises are not looking to jump to Wildfly and/or Spring 6.0, and they depend on a variety of libraries that still expect javax namespaces in their method arguments.

This gives us two options:

1. take every call to any third-party library and put it behind a Java Reflection-based API so we can translate from javax to jakarta objects (or vice-versa) for every such API call

.. or ..

2. use a preprocessor to switch the namespaces (and make a bunch of other required changes) and deliver two different sets of SmartClient server framework .jars, along with two sets of Maven archetypes, sample environments, tools, etc

Incredibly, #2 may be better.

However, this does not make sense to do now - other customers (who have support) are asking for actual features, rather than needless churn necessitated by Oracle's intellectual property issues (yes, that's what this really is).

Currently, one of you is looking to very aggressively upgrade to a platform that has taken an extreme stance (Wildfly) and the other doesn't appear to have an actual issue as we understand it. As we hear from more customers, we will figure out how to prioritize this.

In the meantime, if you really need a solution right away, consider our Feature Sponsorship program if you need this work accelerated.

[vivek.more@nuance.com]

We can't remove IDACall approach as it is the only way we are using to handle built-in datasource operations.
So is there any workaround to use IDACall servlet without isomorphic_spring.jar? Or any other approach to handle datasource operations.

[Isomorphic]

IDACall does not depend on Spring. You can remove isomorphic_spring.jar, as previously explained, and IDACall will continue to function.

This means (again as explained previously) that you will not be able to use the Spring-specific features of SmartClient, such as invoking Spring beans from a DMI. If you were using such features, the process of replacing that functionality is straightforward. For DMI in particular, you just use a different lookup approach (maybe CDI) and call your Spring logic from there.

This whole process is going extremely slowly for you, and we cannot continue to give the same advice over and over in this thread, so if you want to get this resolved quickly, we would suggest purchasing either Support or some consulting hours. Thanks.

[EISENMANN]

Thanks for the status update, I understand this position and can bring it up with my management.

More and more of your customers with active support will be forced to update to newer technologies, because more and more of their/our customers expects us to react to CVEs in timely manner in our products. The usual approach is to update to latest versions of external dependencies, which are hopefully still under maintenance. Therefore I am quite sure, you will be forced to face this issue one day (or kill the product, because you will decide, that it is not economically feasible).

Would it be possible to post an update in this chat if the situation changed on your side?

Thank you in advance