ikasaneip / ikasan Goto Github PK

View Code? Open in Web Editor NEW

38.0 26.0 20.0 336.73 MB

Open Source Enterprise Integration Platform

Home Page: www.ikasan.org

License: Other

HTML 0.22% Java 98.46% XSLT 0.49% CSS 0.13% JavaScript 0.35% Shell 0.06% AspectJ 0.22% Batchfile 0.07%

entepriseesb

ikasan's Introduction

Introduction
- A Quick Overview
Services
Developer
- Developer Pre-Requisiites
- Developer Guide
- Component Guide
- Dashboard Guide
- Upgrade Path - steps required to upgrade from the previous Ikasan version
Samples overview

Contributor Best Practices

Ensure logging output from performing mvn clean install is kept to an absolute minimum, as we have a 4MB limit on log output on our ci builds.
Ensure the max log level is INFO for all code
Likewise hibernate.show_sql should always be false
If adding a new component do add a README.md page to explain its configuration and use
For each new component ensure this is demonstrated in a sample module / flow.

Using Eclipse

Install the latest version of eclipse
Launch eclipse and install the m2e plugin, make sure it uses your repo configs (get it from: http://www.eclipse.org/m2e/download/ or install "Maven Integration for Eclipse" from the Eclipse Marketplace)
In eclipse preferences Java->Code Style, import the cleanup, templates, and formatter configs in ikasaneip/ikasan-developer/eclipse in the ikasanEIP repository.
In eclipse preferences Java->Code Style->Code Templates enable the "Automatically add comments" checkbox to ensure the standard copyright notice gets added at the top of classes.
Also in code template under Comments -> Types ensure you add your name to the @author tag
In eclipse preferences Java->Editor->Save Actions enable "Additional Actions"
Use import on the root pom.xml which will pull in all modules
Wait (m2e takes awhile on initial import)

ikasan's People

Contributors

Stargazers

Watchers

Forkers

suetju onepiece10yrs ellouiy source-knights karianna willhains ebela mmalyutin elliotkennedy ckitt djmarafi andari mick-stewart73 chanchaihong alexmihaimzh jamesh4ck3r mriesch robinroos abhijitghonge

ikasan's Issues

Upgraded module to use Ikasan 3.2.3.0 to overcome Scheduled consumer issue but seems like its not fixed and issue is re-appearing

I'm running a module which is on 3.2.3.0 and have a consumer flow which I stop/start for testing purpose and I think the consumer flow issue is still there in the latest version

2022-05-04 17:11:52,934 INFO org.ikasan.component.endpoint.quartz.consumer.ScheduledConsumer [http-nio-10.110.250.114-33070-exec-3] Started scheduled consumer for flow [esb-metrics-mhi-harvestMetricsScheduledConsumer] module [HarvestMetricsScheduledConsumerToJMSFlow] with firetime null] description [null]

And I have to manually restart it for the flow to start scheduled consumer so applied the workaround mentioned earlier i..e persistentRecover=false thought to bring this to your attention as I feel its not working as we thought.

Can't push?

I tried to push my new local branch to origin from within Mizuho's network and it failed with a 403:

$ git status

On branch ssz_add_gitignore

...

$ git push origin ssz_add_gitignore
Username for 'https://github.com':
Password for 'https://[email protected]':
error: The requested URL returned error: 403 Forbidden while accessing https://github.com/ikasanEIP/ikasan.git/info/refs
fatal: HTTP request failed

My local repo config is:
$ git config -l
user.email=[email protected]
user.name=Stefan Szaniszlo
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
remote.origin.fetch=+refs/heads/:refs/remotes/origin/
remote.origin.url=https://github.com/ikasanEIP/ikasan.git
branch.master.remote=origin
branch.master.merge=refs/heads/master

Hibernate Query Cache using excessive Heap

Prior to Hibernate 5.2.12, CriteriaQuery always used SQL literals for numeric parameters, This makes the Hibernate Query Cache record every query which includes a numeric value as being one instance of a discrete query (the value is not parameterised).

Since Hibernate 5.2.12 this feature is parameterisable in code, and since 5.2.13 it is parameterisable by config. To use placeholders for Numeric parameters to CriteriaQuery instances set:

hibernate.criteria.literal_handling_mode=BIND

Without this setting, the default value INLINE applies.

This Ikasan issue is raised as a result of a JProfiler Heap Dump analysis which showed > 1 million Integer instances being reachable from Hibernate's QueryPlanCache.

Invoking rest/metrics API on Ikasan dashboard returning Jibberish response

Upon invoking rest/metrics API with URL below from application and from Ikasan dashboard swagger returns Jibberish response
http://:/rest/metrics/1648141111466/1648141171466

Error when called from application
2022-04-25 11:42:22,052 INFO com.mizuho.esb.mhi.esb.metrics.component.service.MetricsRestServiceImpl [DefaultMessageListenerContainer-3] Looking up Metrics data from dashboard:http://server:port/rest/metrics/1648141111466/1648141171466 2022-04-25 11:42:22,628 ERROR com.mizuho.esb.mhi.esb.metrics.component.service.MetricsRestServiceImpl [DefaultMessageListenerContainer-3] Issue getting metrics for url [http://server:port/rest/metrics/1648141111466/1648141171466] with response [{Unexpected character ('<' (code 60)): expected a valid value (JSON String, Number, Array, Object or token 'null', 'true' or 'false') at [Source: (String)"<!doctype html><html lang="en"><head><script type="text/javascript">window.Vaadin = window.Vaadin || {}; window.Vaadin.theme = window.Vaadin.theme || {};window.Vaadin.theme.flowBootstrap = true;</script><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><base href="."><meta name="viewport" content="width=device-width, initial-scale=1.0"><title>Ikasan - Login</title><style type="text/css">body {height:100vh;width:100%;margin:0;}"[truncated 13133 chars]; line: 1, column: 2]}]

Error when called from Swagger

Error log from Ikasan dashboard]
`2022-04-25 11:47:55.935 [http-nio-10.110.231.54-10000-exec-8] WARN o.i.rest.dashboard.JwtRequestFilter - [Authorization] header does not begin with Bearer String on url [/rest/metrics/1648141111466/1648141171466]
2022-04-25 11:47:55.970 [http-nio-10.110.231.54-10000-exec-8] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.RuntimeException: Error resolving solr flow invocation metric by query [moduleName:(* ) AND flowName:(* ) AND type:metric AND timestamp:[1648141111466 TO 1648141171466]] from the ikasan solr index!] with root cause
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://server:8983/solr: Expected mime type application/octet-stream but got text/html.

<title>Error 401 require authentication</title>

HTTP ERROR 401 require authentication

URI:	/solr/ikasan/select
STATUS:	401
MESSAGE:	require authentication
SERVLET:	default

at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:635) ~[solr-solrj-8.11.1.jar!/:8.11.1 0b002b11819df70783e83ef36b42ed1223c14b50 - janhoy - 2021-12-14 13:50:57]
at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:266) ~[solr-solrj-8.11.1.jar!/:8.11.1 0b002b11819df70783e83ef36b42ed1223c14b50 - janhoy - 2021-12-14 13:50:57]
at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248) ~[solr-solrj-8.11.1.jar!/:8.11.1 0b002b11819df70783e83ef36b42ed1223c14b50 - janhoy - 2021-12-14 13:50:57]
at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:214) ~[solr-solrj-8.11.1.jar!/:8.11.1 0b002b11819df70783e83ef36b42ed1223c14b50 - janhoy - 2021-12-14 13:50:57]`

Full error stack trade -
Ikasan_metrics_call_error_stackTrace.txt

NOTE:
This started to happen after RHEP patching and I had to start Ikasan dashboard manually and I suspect calling http://server:port/rest/metrics/1648141111466/1648141171466 subsequently trying to login to SOLR to http://server:8983/solr and then fails with authentication issue

Steps to reproduce

Restart Ikasan dashboard
Login to Ikasan dashboard as yourself
http://server;port/swagger-ui.html#/metrics-controller/getMetricsUsingGET_2
key in starttime as 0, endtime as 1651065981000
You'll see you get a jibberish response
WORKAROUND: If you harvest metrics data from a module and then try calling Metrics rest API returns empty data or correct data.

WORKAROUND: If you harvest metrics data from a module and then try calling Metrics rest API returns empty data or correct data.

Impedence mismatch between MessageProvider and some backing stores

This relates to interface

org.ikasan.component.endpoint.quartz.consumer.MessageProvider

and its method:

MESSAGE invoke(JobExecutionContext var1);

We use a backing store (a Hazelcast IMap) from which there is no efficient mechanism to get just one arbitrary entry. To satisfy this method signature our implementation essentially fetches all keys from the IMap ( using Map#keySet() ) and then takes just the first element in that Set to provide the necessary MESSAGE instance. Subsequent "invoke" calls must repeat the process, loading the whole keySet() into memory. This is repeated until the IMap is exhausted (we explicitly remove items which we return).

Our problem stems from the fact that this interface expects to return only one MESSAGE.

If instead the interface returned Iterator, then we could construct and return an iterator which would efficiently stream elements from the IMap back to the framework.

If the return type was Iterator, then implementations genuinely wishing to return a single MESSAGE instance could still do so easily (return an iterator over a sngle-valued Collection).

Such a change would require that the framework iterate the returned Iterator to its conclusion, creating as many Task messages as that would dictate. Since for us the method is mutating (we remove each element from the map in turn) we would hope to know that the Iterator will be fully processed before another call to invoke() is initiated. If that "contract" were infeasible, then at least to know that a partially consumed Iterator will be discarded if invoke() is invoked again, so that we do not inadvertently expose two mutating Iterators over the same underlying data.

Other solutions might include a return type of Supplier, such that the Ikasan framework could apply the returned Supplier directly to a Java Stream if that benefited the Ikasan implementation.

The net effect would be a huge performance gain in situations where the taskMap from which Task messages were taken was large and could now be iterated efficiently.

Add constructor Exception(String, Throwable)

Ikasan defines Exception subcasses which support only the Exception(String) and Exception(Throwable) constructors.

The most useful constructor in application code is Exception(String, Throwable) which allows specification of contextual information in the message and the CAUSAL stack trace as the Throwable.

Without this additional constructor application code must pass context information as String and information about the causal exception is lost. Alternative approaches, such as appending causal exception information to the message, are a code smell and should be discouraged.

Performance issue when loading many files with SFTPMessageProvider

If the duplicate check is enabled then there is a performance issue with the SFTPConsumer (the SFTPMessageProvider and related classes).

Basically if the consumer wants to check for a new file and it first results in a list of x files, then it goes through all these files and calls an sql statement to detect if the file is a duplicate. Then it returns the whole filtered lists which gets sorted chronologically later (if enabled). Then it only takes the first file.

Now for the next file the whole process begins again. So e.g. if 4000 files should be consumed (eager = true), to find each next file to process all 4000 files are checked in the DB again and again.

This leads to a 11h of processing time e.g. in my tests with 4000 files, compared to about 1h after the fix.

The fix consists of

not creating unnecessary String for disabled debug logging
Allowing to cache the duplicate file info by making a Cache configurable to the HibernateBaseFileTransferDaoImpl
Sort the files if needed as early as possible, so that we can skip unnecessary processing and directly return the first element, if only one is needed (which is currently the case anyway, as that get(0) is hard coded

I am about to commit the fix and create a PR soon

H2 database shutdown itself in middle of testing and had to run DB recovery which created db back without Ikasan wiretap table

Error in H2 DB while doing load test. and seems like H2 DB shut down while inserting Wiretaps

2022-05-04 10:09:56,413 ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper [DefaultMessageListenerContainer-1] The database has been closed; SQL statement:
insert into IkasanWiretap (Id, ModuleName, FlowName, ComponentName, EventId, PayloadContent, CreatedDateTime, Expiry, Harvested, HarvestedDateTime) values (null, ?, ?, ?, ?, ?, ?, ?, ?, ?) [90098-200]
2022-05-04 10:09:56,413 ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper [DefaultMessageListenerContainer-1] The database has been closed; SQL statement:
insert into IkasanWiretap (Id, ModuleName, FlowName, ComponentName, EventId, PayloadContent, CreatedDateTime, Expiry, Harvested, HarvestedDateTime) values (null, ?, ?, ?, ?, ?, ?, ?, ?, ?) [90098-200]
Producer,flowComponent=org.ikasan.component.endpoint.jms.spring.producer.ArjunaJmsTemplateProducer@37f627d0,transitions=null]], exception is[org.springframework.dao.DataAccessResourceFailureException: could not execute statement; nested exception is org.hibernate.exception.JDBCConnectionException: could not execute statement]
org.springframework.dao.DataAccessResourceFailureException: could not execute statement; nested exception is org.hibernate.exception.JDBCConnectionException: could not execute statement
        at org.spri

Tried restarting but no luck and H2 DB doesn't recover

ng bean with name 'configurationServiceDao' defined in class path resource [configuration-service-conf.xml]: Cannot resolve reference to bean 'configurationServiceSessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'liquibase' defined in class path resource [org/springframework/boot/autoconfigure/liquibase/LiquibaseAutoConfiguration$LiquibaseConfiguration.class]: Invocation of init method failed; nested exception is liquibase.exception.DatabaseException: java.sql.SQLException: Cannot create PoolableConnectionFactory (General error: "java.lang.IllegalStateException: Chunk 58937 not found [1.4.200/9]" [50000-200])
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.resolveMethodArguments(AutowiredAnnotationBeanPostProcessor.java:767)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:719)
at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:119)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:399)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1431)
at org.springf

Following the DB recovery guide, we did try and recover and worked OK but the Ikasan wiretaps table were empty after recovery

Why are we closing the connection as soon as we have created it every time?

ikasan/ikasaneip/component/endpoint/jms-spring/src/main/java/org/springframework/jms/listener/IkasanMessageListenerContainer.java

Line 143 in f80ad68

finally

Ikasan shell to expose env configuration in non-interactive mode

The ikasan shell currently allows the user to access the env in interactive mode as mentioned here - https://github.com/ikasanEIP/ikasan/tree/3.3.x/ikasaneip/ootb/module/scheduler-agent

What would be really handy is to get this in non-interactive mode

What would be even more useful is to support passing in a parameter e.g. env "h2.java.command" and getting back what that evaluates to.

Use case

As a devops developer
I would like to get access to the expanded version of env properties like h2.java.command
So that I can include them in startup scripts like nssm

Part of a typical nssm configuration script

nssm.exe set my-agent-h2 AppParameters "-server -Xms ..... h2.tools.server"
nssm.exe set my-agent AppParameters "-server -Xms ..... command line paramsr"

IkasanStandaloneFlowTestRule : getDeclaredMethod() -> getMethod()

Class IkasanStandaloneFlowTestRule finds getConfiguration() in the flow component via Class.getDeclaredMethod(String, Object[]).

This means that the flow component must explicitly declare getConfiguration(); it is insufficient for the method to be inherited from a parent in the flow component's inheritance hierarchy.

This results in flow component implementations having to rep[eat the definition of getConfiguration() to do nothing other than invoke super.getConfiguration(), or return the configuration object, causing inconsistency of expression and requiring unit test coverage of unnecessary methods.

Class IkasanStandaloneFlowTestRule should instead use Class.getMethod(String, Object[]) which will find and return a method declared in a superclass.

Maintaining process state after agent restart

Ikasan Scheduler Agent
Version 3.3.x

Problem statement
When an agent is stopped (deliberate, accidental, crash) there may be processes (initiated by a command execution job) that are currently executing.
Upon restart, we no longer have any connection to those running processes and as the command execution job recovers, the command within a command execution job might be restarted by the agent (which could have undesirable effects).

Desired outcome
We need to cater for multiple scenarios

Process still running - Upon agent restart, if the process is still running, we do not want to fire the process again, but instead wait for the current running process to complete and report back to the dashboard when that process completes. Ideally we want to report the exit status of the process, otherwise we need to report back that the process finished with an undetermined exit status (meaning operation support would need to verify the status of the job). Clarification - should the undetermined state result in the job being held until verified
Process finished during the downtime of the agent - Upon restart, the agent should report back to the dashboard that the command execution job has completed. See above point about undetermined state.
Reset - If we reset a command execution job (only allowed after the job terminated with error), i.e. the instanceID has not changed by the command execution job should restart i.e. any previous status should be cleared so there is no way for it to interfere with the new job

Issue with Change Set db/drop/db-changeLog-dropFilter.xml added in Ikasan 3.2.x version and causing issues when migrating a Ikasan 3.1.x module

Seems like 2 change log files introduced in kasan 3.2.x version is causing issues when migrating a module from Ikasan 3.1.x version.

<!-- 3.2.x table drop -->
<include file="db/drop/db-changeLog-dropRoleFilter.xml" relativeToChangelogFile="true" />
<include file="db/drop/db-changeLog-dropFilter.xml" relativeToChangelogFile="true" />

The above change set files is actually causing issues when migrating a Ikasan 3.1.x module to Ikasan 3.2.2 as H2 DB would have been created already by 3.1.x version and migrating to Ikasan 3.2.x + or 3.2.3 we encounter the below issue (See error log for detail)

so workaround is

1. Login to H2 DB via command line or H2 console 
2. select * from FILTER; ->> check no rows there (you shouldn't have any)
3. DROP TABLE FILTER ->> manually drop it
4. Now start the module with Ikasan 3.2.3 version and it should work OK.

Error log - when starting up module after migrating to Ikasan 3.2.x

#22-04-20 14:19:42,531 INFO liquibase.logging.core.Slf4jLogger [main] New row inserted into SecurityPolicy
2022-04-20 14:19:42,532 INFO liquibase.logging.core.Slf4jLogger [main] ChangeSet db/data/db-changelog-entity-search-all-modules-policies.xml::entitySearchAllModulesPolicies::ikasan dev ran successfully in 12ms
2022-04-20 14:19:42,540 INFO liquibase.logging.core.Slf4jLogger [main] Table RoleFilter dropped
2022-04-20 14:19:42,540 INFO liquibase.logging.core.Slf4jLogger [main] ChangeSet db/drop/db-changeLog-dropRoleFilter.xml::dropRoleFilter::ikasan dev ran successfully in 6ms
2022-04-20 14:19:42,548 ERROR liquibase.logging.core.Slf4jLogger [main] Change Set db/drop/db-changeLog-dropFilter.xml::dropFilter::ikasan dev failed. Error: Table "Filter" not found; SQL statement:
DROP TABLE PUBLIC."Filter" [42102-200] [Failed SQL: (42102) DROP TABLE PUBLIC."Filter"]
2022-04-20 14:19:42,550 INFO liquibase.logging.core.Slf4jLogger [main] Successfully released change log lock
2022-04-20 14:19:42,555 ERROR org.springframework.boot.web.embedded.tomcat.TomcatStarter [main] Error starting Tomcat context. Exception: org.springframework.beans.factory.UnsatisfiedDependencyException. Message: Error creating bean with name 'org.springframework.security.config.annotation.web.configuration.WebSecurityConfiguration': Unsatisfied dependency expressed through method 'setFilterChainProxySecurityConfigurer' parameter 1; nested exception is org.springframework.beans.factory.BeanExpressionException: Expression parsing failed

A potential NullPointerException bug

Hi all,

Our tool has found a potential NPE bug.

The statement if (xmlExtractor == null && xml instanceof String) at method extractXml indicates that variable xmlExtractor can be null. However, the statement return xmlExtractor.convert(xml); at line 385 directly uses the variable xmlExtractor. Note that the constraints for this branch is xmlExtractor != null || !(xml instanceof String), indicating that the variable xmlExtractor can be null.

Thanks.

Not a file URL - Ikasan module Java 11 bytecode running under Java 17

We thought we'd see what happens when an Ikasan module is launched under Java 17. This activity retained Java 11 bytecode, and merely switched the runtime Java version.

After configuring a module to run under Java 17 we observe the following:

IkasanEIP (v3.2.3)

...

2022-06-09 10:50:47,529 INFO org.springframework.boot.StartupInfoLogger [main] Starting Application using Java 17.0.3 on adl-esbap04 with PID 3899969 (/opt/app/dev/standalone/mymodulename-1.0.2-SNAPSHOT/lib/mymodulename-1.0.2-SNAPSHOT.jar started by cmi2d in /opt/app/dev/standalone/mymodulename-1.0.2-SNAPSHOT)

...

2022-06-09 10:50:52,489 INFO org.springframework.boot.web.embedded.tomcat.TomcatWebServer [main] Tomcat initialized with port(s): 32450 (http)
2022-06-09 10:50:52,504 INFO org.apache.juli.logging.DirectJDKLog [main] Initializing ProtocolHandler ["http-nio-10.160.43.40-32450"]
2022-06-09 10:50:52,505 INFO org.apache.juli.logging.DirectJDKLog [main] Starting service [Tomcat]
2022-06-09 10:50:52,505 INFO org.apache.juli.logging.DirectJDKLog [main] Starting Servlet engine: [Apache Tomcat/9.0.46]
2022-06-09 10:50:53,005 WARN org.apache.juli.logging.DirectJDKLog [main] Failed to scan [jar:file:/opt/app/dev/standalone/mymodulename-1.0.2-SNAPSHOT/lib/mymodulename-1.0.2-SNAPSHOT.jar!/BOOT-INF/lib/spring-webmvc-5.3.18.jar!/] from classloader hierarchy
java.io.IOException: Unable to open root Jar file 'war:file:/opt/app/dev/standalone/mymodulename-1.0.2-SNAPSHOT/lib/mymodulename-1.0.2-SNAPSHOT.jar*/BOOT-INF/lib/spring-webmvc-5.3.18.jar'
	at org.springframework.boot.loader.jar.Handler.getRootJarFile(Handler.java:318)
	at org.springframework.boot.loader.jar.Handler.getRootJarFileFromUrl(Handler.java:300)
	at org.springframework.boot.loader.jar.Handler.openConnection(Handler.java:86)
	at java.base/java.net.URL.openConnection(URL.java:1094)
	at java.base/java.net.URL.openStream(URL.java:1161)
	at org.apache.tomcat.util.descriptor.tld.TldResourcePath.openStream(TldResourcePath.java:127)
	at org.apache.tomcat.util.descriptor.tld.TldParser.parse(TldParser.java:61)
	at org.apache.jasper.servlet.TldScanner.parseTld(TldScanner.java:275)
	at org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan(TldScanner.java:315)
	at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:387)
	at org.apache.tomcat.util.scan.StandardJarScanner.processURLs(StandardJarScanner.java:318)
	at org.apache.tomcat.util.scan.StandardJarScanner.doScanClassPath(StandardJarScanner.java:270)
	at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:233)
	at org.apache.jasper.servlet.TldScanner.scanJars(TldScanner.java:262)
	at org.apache.jasper.servlet.TldScanner.scan(TldScanner.java:104)
	at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:83)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5161)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
	at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
	at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:829)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
	at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
	at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
	at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
	at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.StandardService.startInternal(StandardService.java:433)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
	at org.apache.catalina.startup.Tomcat.start(Tomcat.java:486)
	at org.springframework.boot.web.embedded.tomcat.TomcatWebServer.initialize(TomcatWebServer.java:123)
	at org.springframework.boot.web.embedded.tomcat.TomcatWebServer.<init>(TomcatWebServer.java:104)
	at org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory.getTomcatWebServer(TomcatServletWebServerFactory.java:455)
	at org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory.getWebServer(TomcatServletWebServerFactory.java:204)
	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.createWebServer(ServletWebServerApplicationContext.java:182)
	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.onRefresh(ServletWebServerApplicationContext.java:160)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:577)
	at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:145)
	at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:775)
	at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:448)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:339)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1365)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1354)
	at com.mymodulepackage.Application.main(Application.java:11)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49)
	at org.springframework.boot.loader.Launcher.launch(Launcher.java:107)
	at org.springframework.boot.loader.Launcher.launch(Launcher.java:58)
	at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88)
Caused by: java.lang.IllegalStateException: Not a file URL
	at org.springframework.boot.loader.jar.Handler.getRootJarFile(Handler.java:306)
	... 60 common frames omitted

Difficulties with parsing "Tomcat-style" URLs have been variously mentioned and resolved in recent Spring releases.

My suggestion is to upgrade Ikasan's dependency Spring Boot 2.5.12 -> 2.5.14 which itself curates a more recent version of Tomcat 9 (9.0.63).

If the problem recurs on the most up-to-date 2.5.* Spring Boot then it should be raised as an issue at their github site.