[
https://issues.apache.org/jira/browse/AMBARI-10748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14512641#comment-14512641
]
Tom Beerbower commented on AMBARI-10748:
----------------------------------------
I think that the main objective here is to make sure that we can include
classes and jars in a view that don't conflict other versions of those classes
used by Ambari. We also want to make sure that there aren't any other
obstacles that prevent us from deploying Spring web apps as views. So far,
I've found the following issues that need to be addressed to support Spring
apps as views...
# Class loading order. The classes in the WEB-INF/lib or WEB-INF/classes
should have priority over classes on the parent class loader. There is a bug
here. The fix involves minimal changes and is minimal risk, I think. Fixing
the ClassLoader issue gets past the {{IllegalAccessError}} noted above but
exposes a couple of other issues for Spring apps. This issue could potentially
be a separate Jira since it is not specific to deploying Spring apps.
# Ambari's embedded Jetty server not setup to support JSP. {code}500 JSP
support not configured{code}This is really just configuration (make javac
available) and making sure that the right jsp dependencies
({{jsp-2.1-glassfish, ant, ant-launcher}}) are included for ambari-server.
Again, changes and risk are minimal. This is not Spring specific since we
should support JSPs in any view but in a Spring MVC app the view is usually a
JSP.
# Ambari internal usage of Spring. We currently use Spring to setup the Ambari
web app and we set this as the root context for all of the deployed view web
apps ...
{code}context.getServletContext().setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,
springWebAppContext){code} This results in the following exception because
the root web app context is from a different version of Spring loaded by a
different class loader... {code}java.lang.IllegalStateException: Context
attribute is not of type WebApplicationContext:
org.springframework.web.context.support.GenericWebApplicationContext@774189d0:
startup date [Thu Jan 01 00:00:00 UTC 1970]; parent:
org.springframework.context.support.ClassPathXmlApplicationContext@318511f0
at
org.springframework.web.context.support.WebApplicationContextUtils.getWebApplicationContext(WebApplicationContextUtils.java:124)
at
org.springframework.web.context.support.WebApplicationContextUtils.getWebApplicationContext(WebApplicationContextUtils.java:99)
at
org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:514)
at
org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:484)
at
org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:136)
at javax.servlet.GenericServlet.init(GenericServlet.java:241)
{code} I'm still evaluating this. I'll update this Jira once I have an
understanding of what is involved to fix.
As suggested, I'm developing a simple Spring based web app deployed as view to
work through these issues. I will push the Spring example under
ambari-views/examples once the issues are resolved.
Also, I don't see a workaround in the existing released Ambari. I think that
code changes are required.
> Views: IllegalAccessError: tried to access class
> ------------------------------------------------
>
> Key: AMBARI-10748
> URL: https://issues.apache.org/jira/browse/AMBARI-10748
> Project: Ambari
> Issue Type: Bug
> Reporter: Tom Beerbower
> Assignee: Tom Beerbower
> Fix For: 2.1.0
>
>
> Deploying a spring web app within a view.
> Certain spring jars are being picked up from /usr/lib/ambari-server as
> opposed to my web app's WEB-INF/lib directory.
> For example, when my view web app gets instantiated (when the web.xml is
> processed), classes from the jar spring-context are loaded from:
> {code}
> Latest exception from my view:
> IllegalAccessError: tried to access class
> org.springframework.core.convert.support.NumberToNumberConverterFactory from
> class org.springframework.core.convert.support.DefaultConversionService
> at
> org.springframework.core.convert.support.DefaultConversionService.addScalarConverters(DefaultConversionService.java:79)
> at
> org.springframework.core.convert.support.DefaultConversionService.addDefaultConverters(DefaultConversionService.java:63)
> at
> org.springframework.core.convert.support.DefaultConversionService.<init>(DefaultConversionService.java:50)
> at
> org.springframework.data.solr.core.convert.SolrConverterBase.<init>(SolrConverterBase.java:33)
> at
> org.springframework.data.solr.core.convert.MappingSolrConverter.<init>(MappingSolrConverter.java:73)
> at
> org.springframework.data.solr.core.SolrTemplate.getDefaultSolrConverter(SolrTemplate.java:480)
> at
> org.springframework.data.solr.core.SolrTemplate.afterPropertiesSet(SolrTemplate.java:529)
> at
> org.springframework.data.solr.repository.support.SolrRepositoryFactory.createTemplate(SolrRepositoryFactory.java:88)
> at
> org.springframework.data.solr.repository.support.SolrRepositoryFactory.<init>(SolrRepositoryFactory.java:76)
> at
> hortonworks.hdp.refapp.ecm.service.core.indexstore.SolrIndexStore.initialize(SolrIndexStore.java:54)
> at
> hortonworks.hdp.refapp.ecm.registry.ECMBeanRefresher.refreshIndexStoreInAppContext(ECMBeanRefresher.java:40)
> at
> hortonworks.hdp.refapp.ecm.registry.ECMBeanRefresher.refreshBeans(ECMBeanRefresher.java:28)
> at
> hortonworks.hdp.refapp.ecm.view.DocumentManagementViewService.createAppContext(DocumentManagementViewService.java:138)
> at
> hortonworks.hdp.refapp.ecm.view.DocumentManagementViewService.initialize(DocumentManagementViewService.java:53)
> at
> hortonworks.hdp.refapp.ecm.view.DocumentManagementViewService.getDocumentService(DocumentManagementViewService.java:109)
> at
> hortonworks.hdp.refapp.ecm.view.DocumentManagementViewService.search(DocumentManagementViewService.java:94)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
