[Hibernate-JIRA] Created: (HHH-3826) Hibernate 3.3.1.GA + Javassist issue 3.9.0.GA : java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy (OSGI Server)
by Charles Moulliard (JIRA)
Hibernate 3.3.1.GA + Javassist issue 3.9.0.GA : java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy (OSGI Server)
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3826
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3826
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Reporter: Charles Moulliard
Hi,
I try to use Hibernate 3.3.1.GA in combination with Spring OSGI 1.2.0-rc1. Unfortunately, there is a classloading issue on OSGI :
{code}
Caused by: java.lang.RuntimeException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:174)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxyFactory(JavassistLazyInitializer.java:162)
... 58 more
Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:167)
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:170)
... 59 more
Caused by: java.lang.NoClassDefFoundError: org/hibernate/proxy/HibernateProxy
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:159)
... 60 more
{code}
remark : the package org.hibernate.proxy is defined in the MANIFEST file (section - Import-PAckage)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[Hibernate-JIRA] Created: (HHH-6165) HqlLexer can cause ClassNotFound in OSGi environment
by Jonathan Calvert (JIRA)
HqlLexer can cause ClassNotFound in OSGi environment
----------------------------------------------------
Key: HHH-6165
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6165
Project: Hibernate Core
Issue Type: Patch
Components: core
Affects Versions: 3.6.2, 3.6.1, 3.6.0, 3.6.0.CR2, 3.6.0.CR1, 3.5.6, 3.6.0.Beta4, 3.6.0.Beta3, 3.5.5, 3.6.0.Beta2, 3.6.0.Beta1, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5.0-Final, 3.5.0-CR-2, 3.5.0-CR-1, 3.5.0-Beta-4, 3.5.0-Beta-3, 3.5.0-Beta-2, 3.5.0.Beta-1, 3.3.2
Environment: At least from 3.3.2 on, and at least on Postgres and Derby
Reporter: Jonathan Calvert
Priority: Minor
Attachments: hqllexer.patch
org.hibernate.hql.ast.HqlLexer can cause a ClassNotFound exception in an OSGi environment with a stacktrace like
{code}
org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.ast.HqlToken [hql query here]
at org.hibernate.hql.ast.HqlLexer.panic(HqlLexer.java:80)
at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338)
at org.hibernate.hql.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:54)
...
{code}
The HqlLexer class has antlr.CharScanner as a superclass, as evidenced by the stacktrace. The contents of the method are:
{code}
public void setTokenObjectClass(String cl) {
// Ignore the token class name parameter, and use a specific token class.
super.setTokenObjectClass( HqlToken.class.getName() );
}
{code}
It passes the name of the HqlToken class as a string to CharScanner, which then ultimately attempts to find HqlToken via antlr.Utils. The tokenObjectClass is a protected field. The code can be simplified by simply setting the field directly to HqlToken.class which is obviously already available to the HqlLexer class.
The reason this causes the exception in an OSGi environment is that the context class loader available to ANTLR is limited to what is explicitly declared in the ANTLR bundle. Since ANTLR cannot (and should not) have to know about all the classes that it may be passed, it does not declare an import on the org.hibernate.hql.ast package. By passing the class directly, the lookup is avoided from within the ANTLR package.
{code}
public void setTokenObjectClass(String cl) {
// Ignore the token class name parameter, and use a specific token class.
tokenObjectClass = HqlToken.class;
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[Hibernate-JIRA] Created: (BVAL-237) Expose validated bean via ConstraintValidatorContext
by Gunnar Morling (JIRA)
Expose validated bean via ConstraintValidatorContext
----------------------------------------------------
Key: BVAL-237
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-237
Project: Bean Validation
Issue Type: New Feature
Components: spec-general
Affects Versions: 1.0 final
Reporter: Gunnar Morling
Fix For: 1.1
In the feedback forum a user [suggested|https://forum.hibernate.org/viewtopic.php?f=26&t=1012111] to expose the currently validated bean via {{javax.validation.ConstraintValidatorContext}}.
IMO that's a good addition as it would people allow to create custom cross-field constraints more easily. I'm not sure whether access should be restricted to the current leaf bean or whether also the root bean should be accessible. In the latter case some methods from {{ConstraintViolation}} might just be offered on {{ConstraintValidatorContext}} as well:
{code:java}
getConstraintDescriptor()
getLeafBean()
getPropertyPath()
getRootBean()
getRootBeanClass()
{code}
Another idea would be to have an {{unwrap()}} method on {{ConstraintValidatorContext}} which would allow for BV providers to expose additional functionality. WDYT?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months