JBossDeveloper

Never mind, I found it. Doh, needed to add the VM args to the launch configuration:

Servers tab -> Server Runtime (double click) -> Open launch configuration

Appended "... -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y" and received the message

{code}Listening for transport dt_socket at address: 8787{code}

Sorry I'm really tired! It's 2 A.M. in Germany but I need to get over this thing.

I'll report back ASAP now that I seem to have gotten JDB attached.

Karsten

Here's the output of the 3 dumps:

{code}MSC service thread 1-4[1] dump this.getClass()
 this.getClass() = {
    ANNOTATION: 8192
    ENUM: 16384
    SYNTHETIC: 4096
    cachedConstructor: null
    newInstanceCallerCache: null
    name: "org.hibernate.cfg.beanvalidation.BeanValidationIntegrator"
    allPermDomain: null
    useCaches: true
    declaredFields: null
    publicFields: null
    declaredMethods: null
    publicMethods: null
    declaredConstructors: null
    publicConstructors: null
    declaredPublicFields: null
    declaredPublicMethods: null
    classRedefinedCount: 0
    lastRedefinedCount: 0
    genericInfo: null
    serialVersionUID: 3206093459760846163
    serialPersistentFields: instance of java.io.ObjectStreamField[0] (id=7858)
    reflectionFactory: instance of sun.reflect.ReflectionFactory(id=7859)
    initted: true
    enumConstants: null
    enumConstantDirectory: null
    annotations: null
    declaredAnnotations: null
    annotationType: null
}
MSC service thread 1-4[1] dump this.getClass().getClassLoader()
 this.getClass().getClassLoader() = {
    NO_RESOURCE_LOADERS: instance of org.jboss.modules.ResourceLoaderSpec[0] (id=7874)
    module: instance of org.jboss.modules.Module(id=7876)
    transformer: null
    paths: instance of org.jboss.modules.Paths(id=7877)
    localLoader: instance of org.jboss.modules.ModuleClassLoader$1(id=7878)
    pathsUpdater: instance of java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl(id=7879)
    org.jboss.modules.ConcurrentClassLoader.LOCKLESS: false
    org.jboss.modules.ConcurrentClassLoader.SAFE_JDK: false
    org.jboss.modules.ConcurrentClassLoader.definingLoader: instance of sun.misc.Launcher$AppClassLoader(id=7880)
    org.jboss.modules.ConcurrentClassLoader.GET_PACKAGE_SUPPRESSOR: instance of java.lang.ThreadLocal(id=7881)
    org.jboss.modules.ConcurrentClassLoader.EMPTY_ENUMERATION: instance of java.util.Collections$2(id=7882)
    org.jboss.modules.ConcurrentClassLoader.packages: instance of org.jboss.modules.UnlockedReadHashMap(id=7883)
    java.security.SecureClassLoader.initialized: true
    java.security.SecureClassLoader.pdcache: instance of java.util.HashMap(id=7884)
    java.security.SecureClassLoader.debug: null
    java.lang.ClassLoader.parent: instance of sun.misc.Launcher$AppClassLoader(id=7880)
    java.lang.ClassLoader.parallelLockMap: instance of java.util.concurrent.ConcurrentHashMap(id=7885)
    java.lang.ClassLoader.package2certs: instance of java.util.concurrent.ConcurrentHashMap(id=7886)
    java.lang.ClassLoader.nocerts: instance of java.security.cert.Certificate[0] (id=7887)
    java.lang.ClassLoader.classes: instance of java.util.Vector(id=7888)
    java.lang.ClassLoader.defaultDomain: instance of java.security.ProtectionDomain(id=7889)
    java.lang.ClassLoader.domains: instance of java.util.Collections$SynchronizedSet(id=7890)
    java.lang.ClassLoader.packages: instance of java.util.HashMap(id=7891)
    java.lang.ClassLoader.scl: instance of sun.misc.Launcher$AppClassLoader(id=7880)
    java.lang.ClassLoader.sclSet: true
    java.lang.ClassLoader.loadedLibraryNames: instance of java.util.Vector(id=7892)
    java.lang.ClassLoader.systemNativeLibraries: instance of java.util.Vector(id=7893)
    java.lang.ClassLoader.nativeLibraries: instance of java.util.Vector(id=7894)
    java.lang.ClassLoader.nativeLibraryContext: instance of java.util.Stack(id=7895)
    java.lang.ClassLoader.usr_paths: instance of java.lang.String[16] (id=7896)
    java.lang.ClassLoader.sys_paths: instance of java.lang.String[1] (id=7897)
    java.lang.ClassLoader.assertionLock: instance of java.lang.Object(id=7898)
    java.lang.ClassLoader.defaultAssertionStatus: false
    java.lang.ClassLoader.packageAssertionStatus: null
    java.lang.ClassLoader.classAssertionStatus: null
}
MSC service thread 1-4[1] dump this
 this = {
    LOG: instance of org.hibernate.internal.CoreMessageLogger_$logger(id=7899)
    APPLY_CONSTRAINTS: "hibernate.validator.apply_to_ddl"
    BV_CHECK_CLASS: "javax.validation.Validation"
    MODE_PROPERTY: "javax.persistence.validation.mode"
    ACTIVATOR_CLASS: "org.hibernate.cfg.beanvalidation.TypeSafeActivator"
    DDL_METHOD: "applyDDL"
    ACTIVATE_METHOD: "activateBeanValidation"
    VALIDATE_METHOD: "validateFactory"
}{code}

Hmmm....... what's the above telling me?

Karsten

@Scott:

1. I need to restate: I'm not using WAR deployment really, just JBoss Tools deployment which seems to just copy the whole directory structure to the local instance. (Wrong subject, my bad!) I've manually zipped up the deployed files and issued the command for you to see the dir tree (attached!).

2. I added the two trace loggers to standalone.xml, see server.log attached.

3. I checked the deployment and yes jboss-deployment-structure.xml is present (also see files dump)

Well, if you ask me, the line

{code}11:07:24,541 INFO  [org.hibernate.validator.util.Version] (MSC service thread 1-2) Hibernate Validator 4.2.0.Final{code}

shouldn't be there.

However it was already visible before the JPA tracers. Don't know if this should happen. I'd expect a Hibernate Validator 3.1.0 to be used. Again, I don't know if it should work with 4.2.0.Final though.

Karsten

Scott,

I just pulled the old webapp from my remote server, it deployed to JBAS 7.1 CR1 without any exceptions. The directory structure of my webapp has changed slightly and that's mostly because I have adapted to Maven and its recommended directory structure (or rather for JSF 2 using a deployed "resources" dir).

So there must be something with the dependencies and/or the dir tree structure. I've attached my old deployment's files dump below.

Edit #1: I restored the old DB locally and now my webapp works like a "charm" again.

Edit #2: I've attached the old app's server.log (local JBAS 7.1) and there you can see no traces of Hibernate Validator 4.2.0... I have no idea what triggers Hibernate 4 in my new webapp.

Edit #3: I just realized that my old app wasn't using JTA as can be seen from the persistence unit setup (RESOURCE_LOCAL). I cling to remember having had problems with JTA setup etc., so I omitted transactions entirely for that app (at first). It's something I need to have today however.

Karsten

Tomaz Cerar wrote:

I don't think this is the case, maybe it just needs hibernate-jpa-2.0-api-1.0.1.Final.jar inside application so it won't use one that is defined globaly.

This jar is the same for hibernate 3.6 and 4.x, additionaly maybe exclude of global shoud also be added.

My Maven dependencies already add this JAR to the project and it's also present in the server's deployment. How do I exclude the JBAS JAR then?

I wonder how this all makes sense since I didn't even change the Seam version for both apps.

For seam alternative of createEntityManagerFactory you can create a component that overrides build-in one and you can do there anything you want. This might just help in this case.

I've been using the persistence framework EntityHome/EntityQuery for that project ever since and (again) how should that make sense when nothing in my project concerning Seam has changed? I'm in doubt this is going anywhere.

Karsten

Hello Scott,

When Seam calls javax.persistence.Persistence.createEntityManagerFactory(), the Hibernate 4.0 persistence provider is used.  The javax.persistence.Persistence.createEntityManagerFactory method doesn't know about the difference between Hibernate 4.0 (which is already registered) and the Hibernate 3.6.x jars packaged with the application. 

 

Are there any Seam alternatives, that don't use javax.persistence.Persistence.createEntityManagerFactory()?

I wonder how this all makes sense with my situation. I have my old (online) webapp which works on JBoss AS 7.0.0.Final up to JBoss AS 7.1.0.CR1 using Seam 2.2.2 and it's not kicking in Hibernate 4. Then I changed the project to Maven, now resulting in a different set of deployed libs, a slightly different jboss-deployment-structure.xml, a slightly different dir structure plus the persistence now being JTA (not RESOURCE_LOCAL as the old app) and it's still using Seam 2.2.2 but this time the app is kicking in Hibernate 4.... it doesn't make sense to me!

I'm very unsure/doubtful to look into Seam as the cause.

Soooo stuck.

Karsten