t; moved on. (Ours is not a UI app)
>
> You can check the fixes section of release notes
>
> https://docs.newrelic.com/docs/release-notes/agent-release-notes/java-release-notes/java-agent-820/
>
> https://github.com/newrelic/newrelic-java-agent/pull/1225
>
> வெள்., 1 செப்., 20
Fixed by upgrading New Relic to 8.5.0!
Other environments had this upgraded, but not the failing one.
On Fri, Sep 1, 2023 at 5:26 PM Torsten Krah wrote:
> Am Freitag, dem 01.09.2023 um 15:18 +1000 schrieb Tim N:
> > We're seeing this too, but not in all our environments. We
We're seeing this too, but not in all our environments. We also use
NewRelic.
JSP
Previously rendered to
Now renders to
/path/style.css"/>
Affected Tomcat version is 9.0.78
Tomcat.java:486)
Do you think I need to look into that more, or does it make sense that the
Service.setParentClassLoader() prevents this?
On Thu, Dec 22, 2022 at 9:49 PM Mark Thomas wrote:
> On 21/12/2022 22:37, Tim N wrote:
> > This was fixed by adding "--add-opens=java.base/
ssLoaderFactory.RepositoryType.JAR));
}
ClassLoader myClassLoader =
ClassLoaderFactory.createClassLoader(repositories, null);
Thread.currentThread().setContextClassLoader(myClassLoader);
SecurityClassLoad.securityClassLoad(myClassLoader);
...
Tomcat tomcat = new Tomcat();
tomcat.getService().setParentC
)
On Wed, Dec 21, 2022 at 3:33 PM Tim N wrote:
> Sorry - more of the stack-trace:
> Caused by: java.lang.IllegalAccessError: failed to access class
> com.sun.activation.registries.LogSupport from class
> javax.activation.MimetypesFileTypeMap
> (com.sun.activation.regist
Looks like this is due to a conflict with EE JARs added to replace those
removed when moving from Java 8 to 17.
On Wed, Dec 21, 2022 at 3:33 PM Tim N wrote:
> Sorry - more of the stack-trace:
> Caused by: java.lang.IllegalAccessError: failed to access
(ConfigurableMimeFileTypeMap.java:150)
On Wed, Dec 21, 2022 at 3:28 PM Tim N wrote:
> I tried this:
>
> List repositories = new ArrayList<>();
> repositories.add(new ClassLoaderFactory.Repository(new
> File("/dir1").getAbsolutePath(), ClassLoaderFactory.RepositoryType.DIR));
> repositories.add
til.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)
So the code looks closer to working, but still something major wrong.
achieve what I'm after? If I could get this
working, I could maybe contribute back with "how-to" documentation.
Thoughts?
Also, how do I make embedded Tomcat use my classloader?
On Wed, Dec 14, 2022 at 9:19 PM Mark Thomas wrote:
> On 14/12/2022 03:20, Tim N wrote:
> > I'm
I'm currently using embedded Tomcat 9.0.68 and have encountered the
infamous compatibility issue with ClassLoader.getSystemClassLoader when
upgrading from Java 8 to Java 17.
See
https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
for a good
>From the official documentation
"The all-to-all replication is an algorithm that is only efficient when the
clusters are small. For larger clusters, you should use the BackupManager"
Any ideas on what the limit is or how to measure it? Any good articles?
Will session fail-over work b/w minor versions? i.e. can you cycle through
upgrading Tomcat in a cluster from say 9.0.67 to 9.0.68? Also, is there any
official documentation on this?
t(serverProperties.getProperty("tomcat-clusterAddress"));
localMember.setDomain("publish-cluster");
localMember.setUniqueId(serverProperties.getProperty("tomcat-clusterMemberUniqueId"));
interceptor.setLocalMember(localMember);
}
...and it seems to be fine now.
On
, Oct 9, 2020 at 11:40 AM Tim N wrote:
> > Can you show us how you configured this cluster please?
>
> Sure.
>
> Tomcat tomcat = new Tomcat();
> tomcat.setBaseDir(baseDir);
> tomcat.getServer().setAddress("127.0.0.1");
> tomcat.getServer().setPort(shutDownPort
clusterAddress=192.168.0.2
tomcat-clusterMemberUniqueId={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}
tomcat-clusterMemberCount=1
tomcat-clusterMemberAddress1=192.168.0.3
tomcat-clusterMemberUniqueId1={0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2}
This was initially converted from a server.xml configuration a year ago on
Tomc
Hi,
I'm in the early stages of analysing this problem:
- Tomcat Embedded 9.0.37 with clustering enabled
- SpringBoot application, 2.1.16
- Login with no existing JSESSIONID fails
I can see the following code is executed twice within one request, the
login attempt:
17 matches
Mail list logo
