Announcement

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

    Issues with Isomorphic Servlets with Wildfly 32 and Jakarta

    Hi there, we're trying to migrate to Smartclient 14.1 and are experiencing issues with the Isomorphic Servlets, including the FileAssembly servlet (stacktrace below) and CSS files served from the Iso servlet as well are having stream issues with WildFly 32's Jakarta EE implementation.


    Any suggestions on next steps for debugging this?


    Here is the method call we are using to instantiate the FileAssembly handling:

    Code:
    private void addIsomorphicServlet6(ServletContext container, AnnotationConfigWebApplicationContext ctx) {
    
            ServletRegistration.Dynamic dispatcher = container.addServlet("FileAssembly", new FileAssembly());
            Set<String> mappingConflicts = dispatcher.addMapping("/js/at_js_static.js");
            mappingConflicts.addAll(dispatcher.addMapping("/js/at_js_public_static.js"));
            mappingConflicts.addAll(dispatcher.addMapping("/js/at_js_static_V2.js"));
            mappingConflicts.addAll(dispatcher.addMapping("/js/jav8/at_jav8_assembled.js"));
            mappingConflicts.addAll(dispatcher.addMapping("/js/charts.js"));
            mappingConflicts.addAll(dispatcher.addMapping("/js/at_js_public_holdings_static.js"));
            mappingConflicts.addAll(dispatcher.addMapping("/js/at_js_report_static.js"));
    
            if (!mappingConflicts.isEmpty()) {
                for (String s : mappingConflicts) {
                    logger.error("Mapping conflict: " + s);
                }
            }
    
        }
    Strack trace:


    2025-07-12 15:10:33,731 INFO [stdout] (default task-30) === 2025-07-12 15:10:33,731 [k-30] INFO FileAssembler - read config file: C:/programs/deploy/dev.war/isomorphicConfig/fileAssembly.xml

    2025-07-12 15:10:33,731 INFO [stdout] (default task-30) === 2025-07-12 15:10:33,731 [k-30] INFO FileAssembler - Processing dynamically assembled file /js/at_js_static.js

    2025-07-12 15:10:33,735 INFO [stdout] (default task-30) === 2025-07-12 15:10:33,735 [k-30] INFO Download - Using gzipped form of request file:
    C:/programs/deploy/dev.war/isomorphicCache/js/at_js_static.js

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) === 2025-07-12 15:10:33,736 [k-30] ERROR Download - Problem sending static file: C:/programs/deploy/dev.war/isomorphicCache/js/at_js_static.js java.io.IOException: UT010029: Stream is closed

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at io.undertow.servlet@2.3.13.Final//io...treamImpl.java:139)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//org.springframework.security.web.util.OnCommittedResponseWrapper$SaveContextServletOutputStream.write(OnCommittedResponseWrapper.java:639)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//com.isomorphic.util.IOUtil.copyStreams(IOUtil.java:155)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//com.isomorphic.util.IOUtil.copyStreams(IOUtil.java:111)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//com.isomorphic.util.IOUtil.copyStreams(IOUtil.java:93)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//com.isomorphic.servlet.ServletTools.sendStaticFile(ServletTools.java:2071)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//com.isomorphic.servlet.ServletTools.sendStaticFile(ServletTools.java:1525)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//com.isomorphic.servlet.FileAssembly.doGet(FileAssembly.java:113)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at jakarta.servlet.api@6.0.0//jakarta.s...tpServlet.java:527)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//com.isomorphic.servlet.BaseServlet.service(BaseServlet.java:178)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at jakarta.servlet.api@6.0.0//jakarta.s...tpServlet.java:614)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at io.undertow.servlet@2.3.13.Final//io...etHandler.java:74)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at io.undertow.servlet@2.3.13.Final//io...erHandler.java:129)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:117)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at io.undertow.servlet@2.3.13.Final//io...gedFilter.java:67)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at io.undertow.servlet@2.3.13.Final//io...erHandler.java:131)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:186)

    2025-07-12 15:10:33,736 INFO [stdout] (default task-30) at deployment.dev.war//org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)



    #2
    Although it's unlikely to be the problem here, note that FileAssembly.addMapping() is not a documented API.

    As far as the stack trace, it indicates that we were outputting to a stream and something else - like the Spring filter servlet - closed the stream.

    Are you seeing actual issues in the application, or just seeing these exceptions in your logs? Because this may be a very ordinary circumstance: someone navigates to your app, starts to download files, then navigates away. The browser kills the connections, then you would expect, on the server, to see an exception like this.

    So it may simply be that your logging is set up to be a bit histrionic.

    Comment


      #3
      Hi there thanks for the reply. We are seeing this in our local environment while we are testing 14.1 with Jakarta and Wildly32 and it appears to be fatal. That file referenced in the logs I pasted ("at_js_static.js ") is critical to our application and it appears this exception is stopping that file from loading. Also, CSS files are being handled by your servlet and we are getting exceptions for those too.

      There is another additional issue we are seeing when trying to load our application and we aren't sure if this is also related but not sure how to debug this one either. This ATUser datasource is the only datasource not working and this is a long established datasource for us: "2025-07-17 10:42:23,041 INFO [stdout] (default task-5) ^[[33m=== 2025-07-17 10:42:23,041 [sk-5] WARN RequestContext - dsRequest.execute() failed: com.isomorphic.datasource.OperationNotSupportedException: Operation type 'fetch' not supported by this DataSource (ATUser)

      Comment


        #4
        To reiterate: are you seeing actual end users getting partial CSS files? If not, then this exception simply indicates that a user navigated away mid load. In that case, no actual error has occurred for the end user.

        As far as the other error, best to start a second thread with the details of that, including the DataSource. Generally speaking, this would indicate that you have added an operationBinding for the default "fetch" operation (no operationId) and you required a role that the current user does not have. But details can be shared in the new thread, including the DataSource.

        Comment


          #5
          Thank you for the prompt response. This is all local development and no end users involved. So, I am the local end user and I am not navigating away mid load. But, it does appear that these resources are in fact loading just fine somehow on further inspection so I'm not sure why this is happening just yet and if it is harmless then we'd just want some way to suppress these exceptions. Also just to clarify addMapping is a valid method for jakarta.servlet.ServletRegistration and that is how we are using it here.

          I have started another thread about the datasource issues we are seeing.

          Comment


            #6
            Ah right, you are correct about addMapping.

            What we suspect is that even though you as the end user are not navigating away mid-load, it's happening in some automated way. A simple example would be arriving at the login screen and resources are being loaded in the background (FileLoader) then you complete login and are redirected to the main screen, with some resources only partially loaded.

            Another might an iframe being opened where the default URL is the same screen you're on, or perhaps on a page that also has background resource loading code, and then the URL is changed later before the resources are loaded.

            Comment

            Working...
            X