Rice 2.1.5 JDK 7 => JDK 8 upgrade

28 views
Skip to first unread message

Berkoff, Alexis (Alex) Contractor, eDataTech

unread,
Apr 22, 2020, 12:05:32 PM4/22/20
to rice....@kuali.org, kc.techni...@kuali.org

Hello –

 

We are upgrading our Kuali Coeus application from JDK 7 => JDK 8 (well, we would have liked to do JDK 11 but that’s another topic/question).

(KC 5.1.0, Rice 2.1.5 bundled).

The build process remained unaffected – but when deploying the newly built application in Tomcat, we are seeing the following during the Tomcat startup –

 

2020-04-21 10:57:53,750 [localhost-startStop-1] u:/d: INFO  org.objectweb.jotm - stop JOTM

2020-04-21 10:57:54,354 [localhost-startStop-1] u:/d: ERROR org.kuali.rice.core.web.listener.KualiInitializeListener - problem during context.refresh()

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'kenConfigurer' defined in class path resource [org/kuali/kra/RiceOverridesSpringBeans.xml]: Invocation of init method failed; nested exception is java.lang.ArrayIndexOutOfBoundsException: 20991

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1455)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)

        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)

        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)

        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)

        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)

        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)

        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:913)

        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:464)

        at org.kuali.rice.core.web.listener.KualiInitializeListener.contextInitialized(KualiInitializeListener.java:91)

        at org.kuali.kra.infrastructure.KraServiceLocatorListener.contextInitialized(KraServiceLocatorListener.java:29)

        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4699)

        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5165)

        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:743)

        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:719)

        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:714)

        at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:970)

        at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1841)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at java.lang.Thread.run(Thread.java:748)

Caused by: java.lang.ArrayIndexOutOfBoundsException: 20991

        at org.springframework.asm.ClassReader.<init>(Unknown Source)

        at org.springframework.asm.ClassReader.<init>(Unknown Source)

        at org.springframework.asm.ClassReader.<init>(Unknown Source)

        at org.springframework.core.LocalVariableTableParameterNameDiscoverer.inspectClass(LocalVariableTableParameterNameDiscoverer.java:112)

        at org.springframework.core.LocalVariableTableParameterNameDiscoverer.getParameterNames(LocalVariableTableParameterNameDiscoverer.java:86)

        at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:193)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1035)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:939)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:485)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)

        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)

        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)

        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)

        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)

        at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:322)

        at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)

        at org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:630)

        at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:148)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1035)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:939)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:485)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)

        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)

        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)

        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)

        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)

        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)

        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:913)

        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:464)

        at org.kuali.rice.core.framework.resourceloader.SpringResourceLoader.start(SpringResourceLoader.java:86)

        at org.kuali.rice.core.api.resourceloader.ResourceLoaderContainer.start(ResourceLoaderContainer.java:52)

        at org.kuali.rice.core.framework.resourceloader.BaseResourceLoader.start(BaseResourceLoader.java:98)

        at org.kuali.rice.core.framework.config.module.ModuleConfigurer.initializeResourceLoaders(ModuleConfigurer.java:311)

        at org.kuali.rice.core.framework.config.module.ModuleConfigurer.afterPropertiesSet(ModuleConfigurer.java:90)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452)

        ... 24 more

2020-04-21 10:57:54,465 [localhost-startStop-1] u:/d: INFO  org.apache.tiles.access.TilesAccess - Publishing TilesContext for context: org.apache.tiles.servlet.context.ServletTilesApplicationContext

 

Does anyone have a sense of how and where to resolve this error?  (Works fine when built with JDK7).

 

Thanks.

 

Alex

 

Alex M Berkoff

Naval Postgraduate School

ITACS / DevOps

Kuali Java Developer (Contractor, eDataTech)

Office: 831-656-2893

Email: ambe...@nps.edu

Ken Geis

unread,
Apr 22, 2020, 12:46:56 PM4/22/20
to Berkoff, Alexis (Alex) Contractor, eDataTech, rice....@kuali.org, kc.techni...@kuali.org
Here's my guess.

I see that Rice 2.1.5 uses Spring 3.1.0.RELEASE. Looking at this blog about the release of Spring 4.0M1, it says that Spring 4 has

the first wave of Java SE 8 / OpenJDK 8 support

and

Spring Framework 3.2.x will support deployment on JDK 8 runtimes for applications compiled against JDK 7 (with -target 1.7) or earlier. Note that it won’t support JDK 8’s bytecode format (-target 1.8, as needed for lambdas); please upgrade to Spring Framework 4.0 for that purpose.

I don't know how I avoided this issue! I'm compiling with JDK8, and for our custom code, I specify 1.8 source and do not specify target (implying 1.8). I run on JRE8. It must be that Spring doesn't scan my code for autowiring/etc.


Ken

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to kc.technical.co...@kuali.org.

Ken Geis (he/him/his) 
Acting Director, IT 
Research Administration and Compliance 
University of California, Berkeley 
LinkedIn | rac.berkeley.edu | berkeley.edu

Ronald Gouldner

unread,
Apr 22, 2020, 12:54:24 PM4/22/20
to Berkoff, Alexis (Alex) Contractor, eDataTech, kc.techni...@kuali.org, rice....@kuali.org
Have you seen this stack overflow?

Not sure why you would get a lambda error in code that compiles in java 7 unless they have something in the code which compiles differently if java 8 is detected.  

Ron

--

Berkoff, Alexis (Alex) Contractor, eDataTech

unread,
Apr 23, 2020, 1:00:46 PM4/23/20
to Ken Geis, rice....@kuali.org, kc.techni...@kuali.org

Ken,

 

Just a follow-up to this one.  Since we’re using the bundled version of RICE with our KC instance – what is the approach at upgrading the version of SPRING that is being declared in RICE pom?

 

From: Ken Geis <kg...@berkeley.edu>
Sent: Wednesday, April 22, 2020 9:47 AM
To: Berkoff, Alexis (Alex) Contractor, eDataTech <ambe...@nps.edu>
Cc: rice....@kuali.org; kc.techni...@kuali.org
Subject: Re: [kuali] Rice 2.1.5 JDK 7 => JDK 8 upgrade

 

NPS Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Ken Geis

unread,
Apr 23, 2020, 4:18:52 PM4/23/20
to Berkoff, Alexis (Alex) Contractor, eDataTech, rice....@kuali.org, kc.techni...@kuali.org
I can't imagine doing a major version upgrade of Spring without upgrading Rice.

If I wanted to try that myself, I use Gradle to build a WAR overlay, and I would:
  • Make my war task exclude the Spring JARs that are pulled in from the KC WAR.
    • Try excluding the entire dependency tree of the Spring 3 JARs.
  • Add dependencies to the Spring 4 libraries that correspond to the Spring 3 ones I excluded. Transitive dependencies should be included automatically.

I would probably focus on targeting Java 7 bytecode in my compilation or configuring Spring not to scan my custom classes.


Ken

Ronald Gouldner

unread,
Apr 23, 2020, 5:27:06 PM4/23/20
to Ken Geis, Berkoff, Alexis (Alex) Contractor, eDataTech, rice....@kuali.org, kc.techni...@kuali.org
Interesting point about target bytecode.   I wonder if Alex compiles using the Java 8 compiler but targets Java 7 bytecode, could that prevent the runtime error ?

Java is moving so fast with it's versions now and has such a short support life span on most versions.  Having to upgrade is going to be a continuous effort leaving little time to do much else.   Given the number of deprecated code warnings I get when I build our 6.1709 version I think upgrading to 11 (LTS) is going to be painful but very necessary soon.  Is targeting a lower bytecode using the more recent and supported version of the compiler a possible solution to this challenge?

Ron

Berkoff, Alexis (Alex) Contractor, eDataTech

unread,
Apr 23, 2020, 8:19:05 PM4/23/20
to Ronald Gouldner, Ken Geis, rice....@kuali.org, kc.techni...@kuali.org

Ron/Ken/Community,

 

I just tried out Ron’s suggestion.

 

kc_project pom

 

$mvn generate-sources

$mvn install

Both execute successfully

(BTW – I did try setting the source to 1.8, but the compiler complains that both source and target need to be 1.8 – so I reverted back to what you see above)

 

kc_custom pom

 

$mvn package

War file is created

(Again - I did try setting the source to 1.8, but the compiler complains that both source and target need to be 1.8.  I also tried setting both to 1.8 and I still get the run time error below).

 

Error during boot-up:

 

@Ken Geis

Notice the error occurs in org.kuali.rice.core.web.listener.KualiInitializeListener class.

You mentioned that I should exclude the Spring 3 references from the project build – but that wouldn’t affect the version of Spring that Rice is using hence wouldn’t I still hit this error if I tried updating my Spring version for the KC project as you suggested?

 

Anyone else in the Rice community see something or know something…been hitting my head against this monitor for too long!? 

 

Alex

Berkoff, Alexis (Alex) Contractor, eDataTech

unread,
May 13, 2020, 6:09:53 PM5/13/20
to Berkoff, Alexis (Alex) Contractor, eDataTech, Ken Geis, kc.techni...@kuali.org, rice....@kuali.org

Hey everybody,

 

Just an update on this.  I’ve ended up upgrading the version of Rice that our KC instance was using.

We went from 2.1.5 => 2.3.14.

This latest 2.3 version of Rice was as high as we could go due to the fact that our version of KC was still using OJB and 2.4.0 jumped to using JPA.

We’ll get there eventually – but for now this is good enough because this version of rice allows us to move to JDK8 because the version of Spring in that Rice is 3.2.x which as @Ken Geis pointed out (in the thread below) allows us to build with JDK8 but target 1.7 bytecode.  Problem solved!  😊

 

I’ve completed the upgrade and just working out some minor kinks here and there due to some customizations that we did in our version of the 2.1.5 rice code.

 

One thing I did notice is that the KC application Tomcat startup cycle (running on this newer version of rice) has nearly tripled.

Overall the startup cycle was about 3 minutes but now it is borderline 9 minutes.

Can anyone comment on the reasons behind this radical jump and if there are remedies at reducing this cycle (e.g. Tomcat Jar scanning exclusions)?

 

// AB

Reply all
Reply to author
Forward
0 new messages