Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Isomorphic
    replied
    As far as the reason to ask this question, we assume that you are being required to move to more recent versions, not for valid functional or security reasons, but simply because it is "the latest".

    If, instead, there is an actual functional or security concern, please do post it here (a separate thread is better) and we will resolve it, quickly.

    As far as what we're going to do about this namespace shift (which again is due to Oracle losing a lawsuit, and has nothing to do with either functional or security concerns), the current plan is to do a namespace shift with the 14.0 release, which will be essentially the 13.1 release but with more features enabled and with this namespace shift.

    Customers who do not want to do this meaningless, non-functional namespace shift will, it seems, end up having to ask us to port 14.0+ features back to the earlier versions, and end up absorbing that cost. We'd like to apologize in advance for this; we would like to offer a better option, but this seems to be the only thing we can do, given Oracle's losses in court.

    Whether you want the "new" namespaces or not, if you want to be involved with this process, and get pre-releases of the changed software you can use to test your application, and so forth, please contact us about ways to be involved. If you are a paying customer with Support, we would be happy to keep you updated as to the latest progress in dealing with this issue, if you wish.

    Leave a comment:


  • rle125
    replied
    Checking to see if there have been any updates on this issue. We're also looking to upgrade to Tomcat 10 and would like to know if the recommendations above still apply.

    Leave a comment:


  • Isomorphic
    replied
    Please see post #12 above:

    https://forums.smartclient.com/forum...955#post269955

    We can't go back and switch an existing release to Jakarta. Overall, there are still many popular third-party libraries out there that have not migrated, so it's not just our software involved (that would be easy), but our dependencies and integrations.

    What we would recommend is:

    1) postpone your Tomcat 10 migration for at least one major release of your software. Tomcat 9 to Tomcat 10 was almost entirely just switching namespaces - there were almost no new features. There is no reason in terms of application functionality, or in terms of security, reliability, or any other factor, to move immediately.

    You may have some very specific, functional reason to move to Tomcat 10, but with most customers we've talked to, it turns out to just be a desire to be on the most recent version, with zero functional reasons for the move. It is definitely worth talking about internally.

    2) engage with our consulting arm to figure out the best approach. There are binary transformers that may work, and your situation is likely unique with respect to dependencies that you may indirectly depend upon that don't use the jakarta namespace - we can help you sort all that out, but not just via forums

    Leave a comment:


  • vvijayarajan
    replied
    Hi,

    Was this issue addressed for Smartclient (not smartGWT)?
    We have to upgrade to tomcat 10 - and v10 doesn't support javax servlet, and have to move to jakarta servlet. Can you please help? Thanks.
    Last edited by vvijayarajan; 19 Jan 2024, 13:47.

    Leave a comment:


  • eliasbalasis
    replied
    Originally posted by Crack View Post
    SmartClient (I'm using the non-GWT version) may be also used as a part of an application, working together with other libraries, and that's how we are using it at my company.

    The situation with javax/jakarta is really annoying, and incompatible dependencies are blocking upgrades to current versions of web frameworks, or starting new projects using them. For us it means being stuck with Spring Boot 2.7, which currently isn't a problem, but will start being one next year.
    It has just become a blocking issue for us.
    We have to upgrade to SpringBoot 3.x sooner than expected and we are finding SmartGWT 13.0-p20230315 not being compatible.

    We understand, this is a derivative of intellectual property battle, but it does not stop the march of 3rd party dependencies from needing an alternate build from Isomorphic.
    We appreciate it is probably a big pain for Isomorphic having to support the "jakarta" flavours, but ultimately Isomorphic must adapt, or suffer consequences as people will eventually stop using the Isomorphic solutions, ourselves included.
    I cannot reveal the name of the global organisation I am working for, but we have a portfolio of UI applications based on SmartGWT whose future development is now becoming more and more compromised.
    Last edited by eliasbalasis; 16 Jun 2023, 07:22.

    Leave a comment:


  • Crack
    replied
    SmartClient (I'm using the non-GWT version) may be also used as a part of an application, working together with other libraries, and that's how we are using it at my company.

    The situation with javax/jakarta is really annoying, and incompatible dependencies are blocking upgrades to current versions of web frameworks, or starting new projects using them. For us it means being stuck with Spring Boot 2.7, which currently isn't a problem, but will start being one next year.

    Leave a comment:


  • Isomorphic
    replied
    This comment is very strange.

    Are you aware that this transition to Jakarta offers no functional benefit and the reason for it is Oracle’s losses in the courts?

    That’s what this is - this is not innovation and not the “latest and greatest”, this is just everyone going through a compatibility nightmare because of Oracle’s legal maneuvering.

    Meanwhile, we are actually innovating: you should look at Reify, also, stay tuned for announcements around AI.

    Anyway, if there is some specific use case that you believe Wildfly will address, feel free to explain the use case and we can offer an approach that does not involve enthusiastically embracing Oracle’s courtroom losses.

    Meanwhile, we have to maintain cross-version compatibility, because that’s what most customers require. But, if you are really in need, you can accelerate development of a compatibility layer that no other customer has requested- via Feature Sponsorship.

    Finally, note that there are no security vulnerabilities that actually apply to our product and there has only been one legit vulnerability in our 20+ year history, and that was minor (information exposure only).

    Leave a comment:


  • EISENMANN
    replied
    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

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • vivek.more@nuance.com
    replied
    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.

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • vivek.more@nuance.com
    replied
    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.

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • vivek.more@nuance.com
    replied
    Hi Team, Any update on this.

    Leave a comment:

Working...
X