Announcement Announcement Module
Collapse
No announcement yet.
slf4j and jsr303 validation conflict Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • slf4j and jsr303 validation conflict

    Hello,

    I've some problems with hibernate-validation 4.1.

    I've change pom dependency from hibernate-validation 4.0.1 to 4.1 and now I cant start my application on glassfish 3.0.1 (don't know how about any other server) because server throw following error:

    Code:
    org.apache.catalina.LifecycleException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'messageInterpolator' defined in ServletContext resource [/WEB-INF/config/spring-messages.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.hibernate.validator.messageinterpolation.ResourceBundleMessageInterpolator]: Constructor threw exception; nested exception is java.lang.LinkageError: loader constraint violation: when resolving method "org.hibernate.validator.util.LoggerFactory.make()Lorg/slf4j/Logger;" the class loader (instance of org/glassfish/web/loader/WebappClassLoader) of the current class, org/hibernate/validator/resourceloading/PlatformResourceBundleLocator, and the class loader (instance of org/apache/felix/framework/ModuleImpl$ModuleClassLoader) for resolved class, org/hibernate/validator/util/LoggerFactory, have different Class objects for the type org/slf4j/Logger used in the signature
            at org.apache.catalina.core.StandardContext.start(StandardContext.java:5289)
            at com.sun.enterprise.web.WebModule.start(WebModule.java:499)
            at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:928)
            at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
    ...
    Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.hibernate.validator.util.LoggerFactory.make()Lorg/slf4j/Logger;" the class loader (instance of org/glassfish/web/loader/WebappClassLoader) of the current class, org/hibernate/validator/resourceloading/PlatformResourceBundleLocator, and the class loader (instance of org/apache/felix/framework/ModuleImpl$ModuleClassLoader) for resolved class, org/hibernate/validator/util/LoggerFactory, have different Class objects for the type org/slf4j/Logger used in the signature
            at org.hibernate.validator.resourceloading.PlatformResourceBundleLocator.<clinit>(PlatformResourceBundleLocator.java:38)
            at org.hibernate.validator.messageinterpolation.ResourceBundleMessageInterpolator.<init>(ResourceBundleMessageInterpolator.java:100)
            at org.hibernate.validator.messageinterpolation.ResourceBundleMessageInterpolator.<init>(ResourceBundleMessageInterpolator.java:86)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
            at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
            at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
            at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:126)
            ... 57 more
    It seems, problem is in implementation of the org/hibernate/validator/util/LoggerFactory that cause two different ways for loading sl4j-api, but I can't imagine how to resolve it

    If you have any idea about it, please help me

    Thanks

    UPD1: Logger.class.getClassLoader().getClass() in old revision of application (witout hibernate-validation 4.1) returns org/glassfish/web/loader/WebappClassLoader
    Last edited by andrey.davydov; Apr 6th, 2011, 01:59 AM. Reason: update

  • #2
    Hello

    Perhaps you should update slf4j version dependency too?
    to let it work in peace with hibernate-validation 4.1.

    Comment


    • #3
      I've tried 1.5.8 and 1.6.1 versions of slf4j. Hibernate core and Hibernate validation depends on different versions of slf4, so I use exclusions for slf in hibernate dependency declaration and add slf4 dependency directly.

      But application doesn't start.

      I've made one experiment. I rebuild org/hibernate/validator/resourceloading/PlatformResourceBundleLocator without using org/hibernate/validator/util/LoggerFactory, i.e. directly call
      Code:
      org.slf4j.LoggerFactory.getLogger(PlatformResourceBundleLocator.class);
      This inplementation starts, but underlayed ResourceBundle fails during reflective resource loading.

      Comment


      • #4
        I have the same problem. Anyone find a solution? The LinkageError is stopping me.

        Comment


        • #5
          My solution was to use last coherent versions of libraries

          Comment


          • #6
            Originally posted by andrey.davydov View Post
            My solution was to use last coherent versions of libraries
            Yup! That did it. The original modules of Glassfish 3 contained Hibernate Validator 3. When I updated, I received 4.1.0. Thanks a bunch!!!

            PS: Too bad Glassfish exports its own Hibernate Validator into the WAR's classpath. That's an implementation leak. The implementation of JSR-303 should be totally hidden from other class loaders. But... perhaps this is a special situation, because because the BV API allows access to the ConstraintValidator implementations.
            Last edited by paul4christ79; Jul 19th, 2011, 08:16 AM.

            Comment

            Working...
            X