NoClassDefFoundError при попытке инициализировать ehcache через файл XML - PullRequest
0 голосов
/ 08 мая 2018

У меня случайно возникает эта проблема, когда я пытаюсь инициализировать ehcache:

Caused by: org.jboss.weld.exceptions.WeldException: WELD-000049 Unable to invoke [method] @PostConstruct private cerebro84.util.cache.CacheManagerServiceBean.initialize() on cerebro84.util.cache.CacheManagerServiceBean@3ee90439
                at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:405)
                at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.postConstruct(ManagedBean.java:178)
                at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:298)
                at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:103)
                at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90)
                at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
                at cerebro84.util.cache.CacheManagerServiceBean$Proxy$_$$_WeldClientProxy.getFromCache(CacheManagerServiceBean$Proxy$_$$_WeldClientProxy.java)
                at cerebro84.util.cache.CacheMethodInterceptor.getResultFromCache(CacheMethodInterceptor.java:29)
                ... 
Caused by: java.lang.reflect.InvocationTargetException
                at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                at java.lang.reflect.Method.invoke(Method.java:498)
                at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267)
                at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
                at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
                at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
                at org.jboss.weld.introspector.jlr.WeldMethodImpl.invoke(WeldMethodImpl.java:168)
                at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:403)
                ... 210 more
Caused by: java.lang.NoClassDefFoundError: net/sf/saxon/trans/XPathException
                at net.sf.saxon.IdentityTransformerHandler.startDocument(IdentityTransformerHandler.java:110)
                at com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader$State.<init>(DomLoader.java:83)
                at com.sun.xml.bind.v2.runtime.unmarshaller.DomLoader.startElement(DomLoader.java:118)
                at com.sun.xml.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:60)
                at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:528)
                at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:507)
                at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:75)
                at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement(SAXConnector.java:178)
                at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:244)
                at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281)
                at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250)
                at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:281)
                at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:250)
                at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:127)
                at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:369)
                at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:348)
                at org.ehcache.xml.ConfigurationParser.<init>(ConfigurationParser.java:177)
                at org.ehcache.xml.XmlConfiguration.parseConfiguration(XmlConfiguration.java:178)
                at org.ehcache.xml.XmlConfiguration.<init>(XmlConfiguration.java:166)
                at org.ehcache.xml.XmlConfiguration.<init>(XmlConfiguration.java:134)
                at org.ehcache.jsr107.EhcacheCachingProvider$ConfigSupplier.getConfiguration(EhcacheCachingProvider.java:327)
                at org.ehcache.jsr107.EhcacheCachingProvider.getCacheManager(EhcacheCachingProvider.java:127)
                at org.ehcache.jsr107.EhcacheCachingProvider.getCacheManager(EhcacheCachingProvider.java:78)
                at org.ehcache.jsr107.EhcacheCachingProvider.getCacheManager(EhcacheCachingProvider.java:186)
                at cerebro84.util.cache.CacheManagerServiceBean.initialize(CacheManagerServiceBean.java:38)
                ... 220 more

Странное поведение в том, что если я перезапустил контейнер (weblogic), он работает нормально. Это класс, который я использую для инициализации кэша, обрезая до самого необходимого:

import javax.annotation.PostConstruct;
import javax.cache.CacheManager;
import javax.cache.Caching;
import javax.enterprise.context.ApplicationScoped;

import lombok.Getter;
import lombok.extern.slf4j.Slf4j;

@Slf4j
@ApplicationScoped
public class CacheManagerServiceBean {
    private static final String EHCACHE_CONFIG_FILE_PATH = "/ehcache.xml";
    @Getter
    private CacheManager cacheManager = null;
    @Getter
    private boolean cacheEnabled = false;

    @PostConstruct
    private void initialize() {
        logger.info("Instantiating cache manager");
        try {
            this.cacheManager = Caching.getCachingProvider().getCacheManager(
                    getClass().getResource(EHCACHE_CONFIG_FILE_PATH).toURI(),
                    getClass().getClassLoader());
            cacheEnabled = true;
        } catch (Exception|NoClassDefFoundError e) {
            logger.error("Unable to enable cache", e);
        }
    }
}

Я попытался добавить следующую строку

<wls:package-name>net.sf.saxon.*</wls:package-name>

до /META-INF/weblogic-application.xml, но это не помогло. Саксонская является прямой зависимостью модуля:

<dependency>
    <groupId>net.sf.saxon</groupId>
    <artifactId>Saxon-HE</artifactId>
    <version>9.5.1-8</version>
</dependency>

Модуль упакован как jar в многомодульном приложении ear. Кто-нибудь знает, как убедиться, что класс XPathException всегда найден саксонским? Заранее спасибо.

1 Ответ

0 голосов
/ 08 мая 2018

Подобные проблемы обычно возникают из-за наличия нескольких разных версий Saxon на пути к классам одновременно.

...