Bug Report: java.lang.IllegalArgumentException: invalid URLPatternSpec

[mkarg]

Brief Summary

Since we migrated (without any other change in EARs or config) from Payara CE 6.2025.9 to Payara CE 7.2025.2, we are getting the following message in server.log:

[2026-01-12T15:08:55.919+0100] [Payara 7.2025.2] [SCHWERWIEGEND] [] [javax.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=93 _ThreadName=http-thread-pool::http-listener-1(2)] [timeMillis: 1768226935919] [levelValue: 1000] [[
  web_server.excep_authenticate_realmadapter
java.lang.IllegalArgumentException: invalid URLPatternSpec
        at jakarta.security.jacc.URLPatternSpec.setURLPatternArray(URLPatternSpec.java:326)
        at jakarta.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:79)
        at jakarta.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:141)
        at org.glassfish.exousia.AuthorizationService.checkWebResourcePermission(AuthorizationService.java:437)
        at org.glassfish.exousia.AuthorizationService.checkWebResourcePermission(AuthorizationService.java:425)
        at com.sun.enterprise.security.ee.authorization.WebAuthorizationManagerService.hasResourcePermission(WebAuthorizationManagerService.java:413)
        at com.sun.web.security.RealmAdapter.invokeWebSecurityManager(RealmAdapter.java:1492)
        at com.sun.web.security.RealmAdapter.preAuthenticateCheck(RealmAdapter.java:567)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:458)
        at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:726)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:577)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:366)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
        at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:520)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:217)
        at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:190)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:535)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:515)
        at java.base/java.lang.Thread.run(Unknown Source)

As the software seems to be fully functional, I assume this is a bug in Payara.

Note that the deployed EARs do not make any use of Payara's built-in security features (we have custom JAX-RS filters in place to implement security), so it is really strange that the stack trace mentions authentication!

Expected Outcome

Nothing shall be found in log.

Current Outcome

[2026-01-12T15:08:55.919+0100] [Payara 7.2025.2] [SCHWERWIEGEND] [] [javax.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=93 _ThreadName=http-thread-pool::http-listener-1(2)] [timeMillis: 1768226935919] [levelValue: 1000] [[
  web_server.excep_authenticate_realmadapter
java.lang.IllegalArgumentException: invalid URLPatternSpec
        at jakarta.security.jacc.URLPatternSpec.setURLPatternArray(URLPatternSpec.java:326)
        at jakarta.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:79)
        at jakarta.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:141)
        at org.glassfish.exousia.AuthorizationService.checkWebResourcePermission(AuthorizationService.java:437)
        at org.glassfish.exousia.AuthorizationService.checkWebResourcePermission(AuthorizationService.java:425)
        at com.sun.enterprise.security.ee.authorization.WebAuthorizationManagerService.hasResourcePermission(WebAuthorizationManagerService.java:413)
        at com.sun.web.security.RealmAdapter.invokeWebSecurityManager(RealmAdapter.java:1492)
        at com.sun.web.security.RealmAdapter.preAuthenticateCheck(RealmAdapter.java:567)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:458)
        at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:726)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:577)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:366)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
        at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:520)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:217)
        at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:190)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:535)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:515)
        at java.base/java.lang.Thread.run(Unknown Source)

Reproducer

We need to strip down our closed-source EAR experimentally, which needs days to weeks, so if a reproducer is really needed (I think the stack trace is pretty clear) the please contact me.

Operating System

Windows 10 Pro

JDK Version

Zulu JDK 21

Payara Distribution

Payara Server Full Profile

[felixif]

Hello @mkarg,

This issue looks very similar to Issue #7777. Do you have any semicolons (either encoded or unencoded) in your application URL where this stack trace is thrown? If that is the case, I can update the report done by my colleague and accept this issue as well.

Regards,
Felix Ifrim

[mkarg]

The error message looks quite similar, so I assume that it is the same problem. We do not know which URL produces the problem, as it only happens in production (where lots of requests per second are handled). Is there a possibility to enable a traffic log in Payara, to see the actual URL in the log?

If not, let's simply wait for a fix for #7777. If the bug still exists after that, it is proven that it is not the same.

[felixif]

Hello @mkarg,

You can use Access Logs to see all the endpoints that have been accessed in your deployed application. In the admin console you can go under <your-config> -> HTTP Services and enable access logging from there. You may also need go to <your-config> -> Virtual Servers -> <your-virtual-server> and scroll down to the Access Log section. There, you can change the logging from Controlled by HTTP Service to Enabled. In my test, the access logs were empty until I did this last step.

If you can find which URLs are being affected, I can mark this issue as accepted and match it with the same internal issue as #7777.

Kind regards,
Felix

[lprimak]

This is definitely a duplicate as #7777 I will comment there

[mkarg]

Using the Access Log I identified that some of the invoked URLs' path contain semicolons (multiple matrix parameters), but others contain colons. So #7777 plays a role here, but maybe for #7777 the trigger is not only semicolons but also colons:

"127.0.0.1" "NULL-AUTH-USER" "15/Jan/2026:18:31:00 +0100" "GET /api/labels/keys/quipsy:t_extin:6 HTTP/2.0" 503 1071 
"127.0.0.1" "NULL-AUTH-USER" "15/Jan/2026:18:31:39 +0100" "GET /api/inspections/analytics/spcorders;measuredFrom=2026-01-07T23:00:00.000Z;measuredUntil=2026-01-15T22:59:59.999Z HTTP/2.0" 304 0 

As there are lots of URLs called in that moment, I cannot confirm that these are the sole triggers, so let's wait until #7777 is resolved and see if our app runs well then to be 100% sure. Feel free to send me a nightly to try it before publication.

[github-actions]

Greetings,
It's been more than 5 days since we requested more information or an update from you on the details of this issue. Could you provide an update soon, please?
We're afraid that if we do not receive an update, we'll have to close this issue due to inactivity.