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

[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.

[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]

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]

Hi Team, Any update on this.

[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.

[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?

[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

[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

[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?

[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?

[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.