was8 spring5
1.0.0
기사 및 수반되는 코드 프로젝트는 WebSphere 8.5 (WAS) 응용 프로그램 컨테이너의 Spring 5 및 Spring Boot 2 응용 프로그램으로 마이그레이션하는 장애물을 극복하는 방법을 극복합니다. Spring이 업데이트 된 유효성 검사 항아리를 사용함에 따라 문제가 발생하며 기본적으로 업그레이드를 방해하는 부모 일등석 로딩 전략을 사용했습니다.
특히, 클래스 로더를 변경하여 부모를 마지막으로 사용하는 방법에 대한 몇 가지 옵션이 제시됩니다. 또한 Maven Pom.xml의 샘플 JSP 프로젝트에서 Spring 및 Spring Boot에 필요한 특정 항아리를 호출합니다.
이러한 변경으로 인해 투자를 유지하는 동안 지원되는 스프링 버전으로 마이그레이션 할 수 있습니다. 그 제품이 수명이 끝날 때까지입니다.
기본적으로 WebSphere Application Server 8.5.x (WAS8)는 Parent_First 클래스 로더 전략을 사용합니다. 일반적으로 이것은 Application Server (EE) 항아리 버전을 먼저로드하고 배포의 내용보다 우선 순위를 정합니다.
예를 들어, Web-Inf Lib 디렉토리에 유효성 검사 API 버전이있을 수 있지만 클래스 경로는 첫 번째로 선호됩니다. 함께 제공되는 JEE 버전을 유리하게 제시 한 버전을 효과적으로 빙글 빙글 빙글 빙글 : IBM은 알려진 Javax 세트로 애플리케이션 서버를 인증하고 테스트하는 데 많은 시간을 보냈습니다.* Jars와 기본적으로 그렇게 유지하려고합니다.
문지름은 최신 버전의 Spring 5.X 및 Spring Boot 2.X를 사용하려고 할 때 발생하며 해당 버전은 핵심 기능에 대한 최신 버전의 Javax Valtidation 및 Hibernate 검증에 의존합니다. 당신은 무엇을합니까?
옵션 1은 응용 프로그램 서버를 업그레이드하는 것입니다. 이것은 Apache Tomcat, Open Liberty, Jboss 및 기타 여러 오픈 소스 구현으로 간단합니다. 이것은 큰 도전 이었기 때문입니다. 많은 비판적 및 레거시 애플리케이션이 수년간 JDK 8.X로 8.5로 실행되었으며, 비즈니스는 비싼 회귀 테스트 비용을 거의 지불하고 싶지 않습니다. 물론 Spring 4.x는 수명의 끝이지만 여전히 작동하므로 업그레이드하는 이유는 무엇입니까? 가장 좋은 대답은 5.x가 더 시원하며 이력서에 도움이된다는 것입니다. 실제 답변은 취약점입니다. 당신은 더 이상 지원되지 않으며 새로운 취약점이 야생에서 발견되는 경우 문제입니다. 당신은 그 시나리오를 앞서 가고 싶습니다.
9는 무엇입니까? 글쎄, 나는 그것을 당신에게 맡깁니다. 개인적으로 당신이 마이그레이션하는 경우 8은 8입니다. 사용자 정의가 필요하지 않으면 8 기능이 아니라면 위의 오픈 소스 구현은 잘 작동합니다. 모든 환경, 클라우드에서 원하는만큼 원하는만큼 배포 할 수 있습니다. 컨테이너 또는 온 프레임. 당신의 선택과 CFO는 신경 쓰지 않을 것입니다.
우리가 여기서 해결해야 할 옵션은 클래스 로더를 부모에서 부모를 마지막으로 전환하는 것입니다. 이것은 장기적인 해결책이 아닙니다. 이것은 단지 당신을 봄의 지원을 받게되며 당신의 비즈니스는 그 변화에 대해 "봄"을 할 수 있습니다. 당신은 그것을 "봄", 나는 punny입니다. 또한 이것은은 총알이 아닙니다. 귀하의 인프라 팀이 스크립팅에 투자했으며 안정된 클러스터에서 노드를 잘 실행했습니다. 부모와 함께 새 노드를 배포하면 지난부는 마이그레이션되지 않지만 동일한 셀에있는 다른 응용 프로그램에 영향을 줄 수 있습니다. 당신은 거기서 무엇을합니까?
이 작업을 수행하는 방법에는 여러 가지가 있습니다. 우리는 그러한 세부 사항을 탐구하지 않을 것입니다. 나는 당신에게 3 개의 높은 수준의 솔루션을 제공하고 당신을 선택할 수 있습니다.
이것은 가장 위험하고 가장 적게 문서화되어 있습니다. 여기에서 IBM 특정 주석으로 귀에 모호한 XML 파일을 업데이트하고 최선을 다해 희망합니다. 거꾸로 된 것은 스크립트를 변경할 필요가 없다는 것입니다. 단점? 나는 이것이 생산 환경 에서이 작품을 증명할 수 없었습니다. 다음은 주제에 대한 일부 스택 오버플로 기사입니다. 구매자는주의하십시오
이 제품은 WAS의 개발자 버전과 함께 작동하며 관리자 콘솔에 액세스 할 수있는 경우에도 효과적입니다. 이 옵션은 변경 사항을 증명할 수있는 좋은 방법입니다. 물론 주요 문제는 이러한 변화가 확장 가능하지 않거나 스크립트 될 수 없다는 것입니다. 이 옵션이 마음에 들지 않지만 모든 모듈 배포 후 인프라 팀이 귀를 기꺼이 업데이트하지는 않습니다. 이것은 칙칙한 옵션이 아닙니다.
이것은 실제로 생산을위한 유일한 옵션입니다. 배포하는 동안 및 응용 프로그램을 시작하기 전에 클래스 로더를 변경하기 위해 배포 스크립트를 업데이트하려면 인프라 팀과 함께 작업해야합니다. 파트너를 가로 질러 포인트를 얻기 위해 샘플 개발자의 Jython (PY) 파일을 포함 시켰습니다.
여기에서 Jython 스크립트에 대한 내 영감을 볼 수 있습니다.
print ( "Get Deployments : " )
deployments = AdminConfig . getid ( '/Deployment:' + APP_NAME + '/' )
print deployments
print ( "" )
print ( "Deployment Object" )
deploymentObject = AdminConfig . showAttribute ( deployments , 'deployedObject' )
print deploymentObject
myModules = AdminConfig . showAttribute ( deploymentObject , 'modules' )
myModules = myModules [ 1 : len ( myModules ) - 1 ]. split ( " " )
print myModules
for module in myModules :
if ( module . find ( 'WebModuleDeployment' ) != - 1 ):
AdminConfig . modify ( module , [[ 'classloaderMode' , 'PARENT_LAST' ]])
AdminConfig . save ()
print ( "Set module to PARENT_LAST" )이 변화는 완전히 당신에게 있습니다. 변경 사항을 확인하고 검증하려면 개발자 서버 또는 로컬 서버가 필요하지만 유효성 검사 및 최대 절전 모드에 대한 특정 변경 사항으로 POM.XML을 업데이트해야합니다.
처음 배포 한 후 클래스 로더를 변경 한 후 시스템 로그에서 아래 오류가 표시됩니다.
원인 : java.lang.classnotfoundexception : javax.validation.parameternameprovider
Spring 5.x는 Validtion-API 의 버전 2.X에 의존하므로 POM의 API를 명시 적으로 업그레이드해야합니다. 다시 클래스 로더를 변경했기 때문에 가능합니다. 그 변화가 없으면 당신은 클래스 경로에서 버전 1.x를로드하고 있습니다. 근로가 없습니다. JSP 페이지를 사용하는 경우 다른 변경 사항이 있습니다. WAS8-WAR 프로젝트에서 POM.XML을 참조하십시오.
특별 참고 타일 2.x를 사용하는 경우 타일 3.x로 업그레이드해야합니다. 그것은 또 다른 게시물이 될 것입니다.
< dependency >
< groupId >javax.validation</ groupId >
< artifactId >validation-api</ artifactId >
< version >2.0.1.Final</ version >
</ dependency >구체적이지는 않았지만, 우리는 Tomcat-embed-Jasper 의존성을 포함하여 애플리케이션이 로컬 실행을 위해 JSP 페이지를 컴파일하고 렌더링 할 수 있도록해야합니다. 범위가 제공 되지 않습니다
< dependency >
< groupId >org.apache.tomcat.embed</ groupId >
< artifactId >tomcat-embed-jasper</ artifactId >
< version >${tomcat-embed-jasper.version}</ version >
< scope >provided</ scope >
</ dependency >필요한 추가 항아리는 Spring Boot 2.X ReadMe.md를 참조하십시오.
지금까지 갔다면 Java 구성을 사용하고 있습니다. 구식 XML 구성을 잊어 버리십시오. 너무 봄 4.x였습니다. 당신은 지금 그것보다 낫습니다.
JSP 페이지의 위치에 주목하십시오 : /Web-Inf/Views/
@ Configuration
@ EnableWebMvc
@ ComponentScan ( basePackages = { "org.scavino" })
public class AppConfig {
/**
* ViewResolver allows setting properties such as
* prefix (/WEB-INF/views/) or suffix (*.jsp) to the view name to generate
* the final view page URL. In our case this is how
* we will configure JSP pages.
*
* @return JSP resolver with prefix set to /WEB-INF/views/
*/
@ Bean
public InternalResourceViewResolver resolver () {
InternalResourceViewResolver resolver = new InternalResourceViewResolver ();
resolver . setPrefix ( "/WEB-INF/views/" );
resolver . setSuffix ( ".jsp" );
return resolver ;
}
}주요 구성에 액세스하기 위해 AbstractAntationConfigDispatcherservletinitializer를 확장하고 있습니다. 왜? Dispatcherservlet 및/또는 ContextLoaderListener를 수동으로 구성하는 대신 Spring에서 제공하는 편의 클래스를 사용할 수 있습니다.
public class SpringMvcDispatcherServletInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
@ Override
protected Class <?> [] getRootConfigClasses () {
return null ;
}
@ Override
protected Class <?> [] getServletConfigClasses () {
return new Class [] {
AppConfig . class
};
}
@ Override
protected String [] getServletMappings () {
return new String [] {
"/"
};
}
