scottmarlow

/*
 * JBoss, Home of Professional Open Source.
 * Copyright 2011, Red Hat, Inc., and individual contributors
 * as indicated by the @author tags. See the copyright.txt file in the
 * distribution for a full listing of individual contributors.
 *
 * This is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Lesser General Public License as
 * published by the Free Software Foundation; either version 2.1 of
 * the License, or (at your option) any later version.

scottmarlow

public class test1 {

   public static void main(String args[]) {
      final String host = "localhost";
      final int newPort = 9999;
      String s = "service:jmx:remoting-jmx:///" + host + ":"+ newPort;
      if (args.length > 1) {
         s = args[1];
      }      
      try {

scottmarlow

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="org.hibernate" slot="ogm">
    <resources>
        <resource-root path="hibernate-ogm-core-3.0.0-SNAPSHOT.jar"/>
    </resources>

    <dependencies>
        <module name="org.jboss.as.jpa.hibernate" slot="4"/>
        <module name="org.hibernate" slot="main" export="true" />
        <module name="javax.api"/>

scottmarlow

<?xml version="1.0" encoding="UTF-8"?>

<!--
  ~ JBoss, Home of Professional Open Source.
  ~ Copyright 2010, Red Hat, Inc., and individual contributors
  ~ as indicated by the @author tags. See the copyright.txt file in the
  ~ distribution for a full listing of individual contributors.
  ~
  ~ This is free software; you can redistribute it and/or modify it
  ~ under the terms of the GNU Lesser General Public License as

scottmarlow

If you use the @GeneratedValue(AUTO) annotation in your applications, you are using the default strategy for generating unique index values.  For applications that you are migrating to JBoss Enterprise Application Platform 6, changes should be considered before deploying with the @GeneratedValue(AUTO) annotation.  New applications that use the @GeneratedValue(AUTO) annotation, should set the hibernate.id.new_generator_mappings property to true.

Setting the hibernate.id.new_generator_mappings property to true, is the preferred behavior. It is more efficient and closer to the JPA 2 specification. But for existing applications, care must be taken to ensure that newly created entities, use the same generator as was previously used with the application.

When JPA applications are deployed on JBoss Enterprise Application Platform 6, the hibernate.id.new_generator_mappings property defaults to true.  

When Hibernate applications are deployed on JBoss Enterprise Application Platform 6, the hibernate.id.new_generato

scottmarlow

<?xml version="1.0" encoding="UTF-8"?>

<!--
  ~ JBoss, Home of Professional Open Source.
  ~ Copyright 2011, Red Hat, Inc., and individual contributors
  ~ as indicated by the @author tags. See the copyright.txt file in the
  ~ distribution for a full listing of individual contributors.
  ~
  ~ This is free software; you can redistribute it and/or modify it
  ~ under the terms of the GNU Lesser General Public License as

scottmarlow

Applications that use Hibernate directly with Seam 2.2 may use a version of Hibernate 3 packaged inside the application. Hibernate 4, which is provided through the "org.hibernate" module of JBoss Enterprise Application Platform 6, is not supported by Seam 2.2. It is supported by Seam 2.3. This example is intended to help you get your application running on JBoss Enterprise Application Platform 6 as a first step. Please be aware that packaging Hibernate 3 with a Seam 2.2 application is not a supported configuration. You should upgrade your application to use Seam 2.3 and Hibernate 4 as your next migration step.

scottmarlow

<?xml version="1.0" encoding="UTF-8"?>

<!--
  ~ JBoss, Home of Professional Open Source.
  ~ Copyright 2011, Red Hat, Inc., and individual contributors
  ~ as indicated by the @author tags. See the copyright.txt file in the
  ~ distribution for a full listing of individual contributors.
  ~
  ~ This is free software; you can redistribute it and/or modify it
  ~ under the terms of the GNU Lesser General Public License as

scottmarlow

<?xml version="1.0" encoding="UTF-8"?>

<!--
  ~ JBoss, Home of Professional Open Source.
  ~ Copyright 2011, Red Hat, Inc., and individual contributors
  ~ as indicated by the @author tags. See the copyright.txt file in the
  ~ distribution for a full listing of individual contributors.
  ~
  ~ This is free software; you can redistribute it and/or modify it
  ~ under the terms of the GNU Lesser General Public License as

scottmarlow

The idea of having a separate generateSchema() that might do the same work as would of been done in createContainerEntityManagerFactory() (if certain properties are specified), brings to mind some other recent discussions (one that I raised about deployment ordering concerns).  Could we add other methods that provide a multi-step approach to creating the container manager entity manager factory?

The reason for turning createContainerEntityManagerFactory(), into multiple steps, is to allow the EE container to control when different JPA deployment operations can occur.  More specifically, I would like to have control over when the persistence provider performs the following aspects of createContainerEntityManagerFactory():

- Scanning for annotations & adding class transformers (to ensure that this happens before other EE deployers load application classes).

- DataSource is used (this will help with use of @DataSourceDefinition which might not be initialized until after the other EE deployers have at least st