EMF / EM JNDI bindings no longer create subcontexts --------------------------------------------------- Key: EJBTHREE-1685 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1685 Project: EJB 3.0 Issue Type: Bug Components: jpa-deployers Affects Versions: AS 5.0.0.CR1 Environment: NOTE: Issue present in AS 5.0.0.GA (which is not in "Affects Version/s" list yet) Reporter: Matt C Assignee: Andrew Lee Rubinger In JBoss AS 4.2.0.GA / 4.2.1.GA it was possible to bind EM, EMF and hibernate SessionFactory objects to a sub-context in JNDI, e.g. "persistence-units/PU1". The target path was created if it didn't exist. Binding is done here using the following persistence unit properties in persistence.xml: - jboss.entity.manager.jndi.name - jboss.entity.manager.factory.jndi.name - hibernate.session_factory_name In JBoss AS 5.0.0.GA binding to a JNDI sub-context no longer works if the sub-context needs to be auto-created. Binding to a context does work in general (EJBTHREE-1526) but only when the target context exists, e.g. when binding to the root. Applications that require a JNDI sub-context containing it's SFs and EMFs in this manner fail to deploy in 5.0.0.GA. This issue appeared while trying to upgrade an enterprise app from 4.2.1.GA to 5.0.0.GA. PersistenceUnitDeployment.java seems to be the culprit. Method calls to NonSerializableFactory.rebind() are made but to the variant of rebind() that won't auto-create the target context if necessary. This is a change of behavior from 4.2.1.GA. Another rebind() method is available with the argument createSubcontexts = true. If this method was used instead, backwards compatibility would be restored.

EMF / EM JNDI bindings no longer create subcontexts --------------------------------------------------- Key: EJBTHREE-1685 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1685 Project: EJB 3.0 Issue Type: Bug Components: jpa-deployers Affects Versions: AS 5.0.0.CR1 Environment: NOTE: Issue present in AS 5.0.0.GA (which is not in "Affects Version/s" list yet) Reporter: Matt C Assignee: Andrew Lee Rubinger Attachments: EJBTHREE-1685_fix_v1_trunk.patch, EJBTHREE-1685_fix_v2_trunk.patch In JBoss AS 4.2.0.GA / 4.2.1.GA it was possible to bind EM, EMF and hibernate SessionFactory objects to a sub-context in JNDI, e.g. "persistence-units/PU1". The target path was created if it didn't exist. Binding is done here using the following persistence unit properties in persistence.xml: - jboss.entity.manager.jndi.name - jboss.entity.manager.factory.jndi.name - hibernate.session_factory_name In JBoss AS 5.0.0.GA binding to a JNDI sub-context no longer works if the sub-context needs to be auto-created. Binding to a context does work in general (EJBTHREE-1526) but only when the target context exists, e.g. when binding to the root. Applications that require a JNDI sub-context containing it's SFs and EMFs in this manner fail to deploy in 5.0.0.GA. This issue appeared while trying to upgrade an enterprise app from 4.2.1.GA to 5.0.0.GA. PersistenceUnitDeployment.java seems to be the culprit. Method calls to NonSerializableFactory.rebind() are made but to the variant of rebind() that won't auto-create the target context if necessary. This is a change of behavior from 4.2.1.GA. Another rebind() method is available with the argument createSubcontexts = true. If this method was used instead, backwards compatibility would be restored.

EMF / EM JNDI bindings no longer create subcontexts --------------------------------------------------- Key: JBJPA-6 URL: https://jira.jboss.org/jira/browse/JBJPA-6 Project: JBoss JPA Issue Type: Bug Affects Versions: 1.0.0-Beta6 Environment: NOTE: Issue present in AS 5.0.0.GA (which is not in "Affects Version/s" list yet) Reporter: Matt C Assignee: Andrew Lee Rubinger Attachments: EJBTHREE-1685_fix_v1_trunk.patch, EJBTHREE-1685_fix_v2_trunk.patch In JBoss AS 4.2.0.GA / 4.2.1.GA it was possible to bind EM, EMF and hibernate SessionFactory objects to a sub-context in JNDI, e.g. "persistence-units/PU1". The target path was created if it didn't exist. Binding is done here using the following persistence unit properties in persistence.xml: - jboss.entity.manager.jndi.name - jboss.entity.manager.factory.jndi.name - hibernate.session_factory_name In JBoss AS 5.0.0.GA binding to a JNDI sub-context no longer works if the sub-context needs to be auto-created. Binding to a context does work in general (EJBTHREE-1526) but only when the target context exists, e.g. when binding to the root. Applications that require a JNDI sub-context containing it's SFs and EMFs in this manner fail to deploy in 5.0.0.GA. This issue appeared while trying to upgrade an enterprise app from 4.2.1.GA to 5.0.0.GA. PersistenceUnitDeployment.java seems to be the culprit. Method calls to NonSerializableFactory.rebind() are made but to the variant of rebind() that won't auto-create the target context if necessary. This is a change of behavior from 4.2.1.GA. Another rebind() method is available with the argument createSubcontexts = true. If this method was used instead, backwards compatibility would be restored.

EMF / EM JNDI bindings no longer create subcontexts --------------------------------------------------- Key: JBJPA-6 URL: https://jira.jboss.org/jira/browse/JBJPA-6 Project: JBoss JPA Issue Type: Bug Affects Versions: 1.0.0-Beta6 Environment: NOTE: Issue present in AS 5.0.0.GA (which is not in "Affects Version/s" list yet) Reporter: Matt C Assignee: Andrew Lee Rubinger Attachments: EJBTHREE-1685_fix_v1_trunk.patch, EJBTHREE-1685_fix_v2_trunk.patch, JBJPA-6_commoncore.patch, JBJPA-6_jpadeployers.patch In JBoss AS 4.2.0.GA / 4.2.1.GA it was possible to bind EM, EMF and hibernate SessionFactory objects to a sub-context in JNDI, e.g. "persistence-units/PU1". The target path was created if it didn't exist. Binding is done here using the following persistence unit properties in persistence.xml: - jboss.entity.manager.jndi.name - jboss.entity.manager.factory.jndi.name - hibernate.session_factory_name In JBoss AS 5.0.0.GA binding to a JNDI sub-context no longer works if the sub-context needs to be auto-created. Binding to a context does work in general (EJBTHREE-1526) but only when the target context exists, e.g. when binding to the root. Applications that require a JNDI sub-context containing it's SFs and EMFs in this manner fail to deploy in 5.0.0.GA. This issue appeared while trying to upgrade an enterprise app from 4.2.1.GA to 5.0.0.GA. PersistenceUnitDeployment.java seems to be the culprit. Method calls to NonSerializableFactory.rebind() are made but to the variant of rebind() that won't auto-create the target context if necessary. This is a change of behavior from 4.2.1.GA. Another rebind() method is available with the argument createSubcontexts = true. If this method was used instead, backwards compatibility would be restored.

EMF / EM JNDI bindings no longer create subcontexts --------------------------------------------------- Key: JBJPA-6 URL: https://jira.jboss.org/jira/browse/JBJPA-6 Project: JBoss JPA Issue Type: Bug Affects Versions: 1.0.0-Beta6 Environment: NOTE: Issue present in AS 5.0.0.GA (which is not in "Affects Version/s" list yet) Reporter: Matt C Assignee: Andrew Lee Rubinger Attachments: EJBTHREE-1685_fix_v1_trunk.patch, EJBTHREE-1685_fix_v2_trunk.patch, JBJPA-6_commoncore.patch, JBJPA-6_jpadeployers.patch, JBJPA-6_jpadeployers_2.patch In JBoss AS 4.2.0.GA / 4.2.1.GA it was possible to bind EM, EMF and hibernate SessionFactory objects to a sub-context in JNDI, e.g. "persistence-units/PU1". The target path was created if it didn't exist. Binding is done here using the following persistence unit properties in persistence.xml: - jboss.entity.manager.jndi.name - jboss.entity.manager.factory.jndi.name - hibernate.session_factory_name In JBoss AS 5.0.0.GA binding to a JNDI sub-context no longer works if the sub-context needs to be auto-created. Binding to a context does work in general (EJBTHREE-1526) but only when the target context exists, e.g. when binding to the root. Applications that require a JNDI sub-context containing it's SFs and EMFs in this manner fail to deploy in 5.0.0.GA. This issue appeared while trying to upgrade an enterprise app from 4.2.1.GA to 5.0.0.GA. PersistenceUnitDeployment.java seems to be the culprit. Method calls to NonSerializableFactory.rebind() are made but to the variant of rebind() that won't auto-create the target context if necessary. This is a change of behavior from 4.2.1.GA. Another rebind() method is available with the argument createSubcontexts = true. If this method was used instead, backwards compatibility would be restored.

EMF / EM JNDI bindings no longer create subcontexts --------------------------------------------------- Key: JBJPA-6 URL: https://jira.jboss.org/jira/browse/JBJPA-6 Project: JBoss JPA Issue Type: Bug Affects Versions: 1.0.0-Beta6 Environment: NOTE: Issue present in AS 5.0.0.GA (which is not in "Affects Version/s" list yet) Reporter: Matt C Assignee: Andrew Lee Rubinger Fix For: 1.0.0-Beta7 Attachments: EJBTHREE-1685_fix_v1_trunk.patch, EJBTHREE-1685_fix_v2_trunk.patch, JBJPA-6_commoncore.patch, JBJPA-6_jpadeployers.patch, JBJPA-6_jpadeployers_2.patch, JBJPA-6_jpadeployers_2_good.patch In JBoss AS 4.2.0.GA / 4.2.1.GA it was possible to bind EM, EMF and hibernate SessionFactory objects to a sub-context in JNDI, e.g. "persistence-units/PU1". The target path was created if it didn't exist. Binding is done here using the following persistence unit properties in persistence.xml: - jboss.entity.manager.jndi.name - jboss.entity.manager.factory.jndi.name - hibernate.session_factory_name In JBoss AS 5.0.0.GA binding to a JNDI sub-context no longer works if the sub-context needs to be auto-created. Binding to a context does work in general (EJBTHREE-1526) but only when the target context exists, e.g. when binding to the root. Applications that require a JNDI sub-context containing it's SFs and EMFs in this manner fail to deploy in 5.0.0.GA. This issue appeared while trying to upgrade an enterprise app from 4.2.1.GA to 5.0.0.GA. PersistenceUnitDeployment.java seems to be the culprit. Method calls to NonSerializableFactory.rebind() are made but to the variant of rebind() that won't auto-create the target context if necessary. This is a change of behavior from 4.2.1.GA. Another rebind() method is available with the argument createSubcontexts = true. If this method was used instead, backwards compatibility would be restored.

EMF / EM JNDI bindings no longer create subcontexts --------------------------------------------------- Key: JBJPA-6 URL: https://jira.jboss.org/jira/browse/JBJPA-6 Project: JBoss JPA Issue Type: Bug Affects Versions: 1.0.0-Beta6 Environment: NOTE: Issue present in AS 5.0.0.GA (which is not in "Affects Version/s" list yet) Reporter: Matt C Assignee: Andrew Lee Rubinger Fix For: 1.0.0-CR1 Attachments: EJBTHREE-1685_fix_v1_trunk.patch, EJBTHREE-1685_fix_v2_trunk.patch, JBJPA-6_commoncore.patch, JBJPA-6_jpadeployers.patch, JBJPA-6_jpadeployers_2.patch, JBJPA-6_jpadeployers_2_good.patch In JBoss AS 4.2.0.GA / 4.2.1.GA it was possible to bind EM, EMF and hibernate SessionFactory objects to a sub-context in JNDI, e.g. "persistence-units/PU1". The target path was created if it didn't exist. Binding is done here using the following persistence unit properties in persistence.xml: - jboss.entity.manager.jndi.name - jboss.entity.manager.factory.jndi.name - hibernate.session_factory_name In JBoss AS 5.0.0.GA binding to a JNDI sub-context no longer works if the sub-context needs to be auto-created. Binding to a context does work in general (EJBTHREE-1526) but only when the target context exists, e.g. when binding to the root. Applications that require a JNDI sub-context containing it's SFs and EMFs in this manner fail to deploy in 5.0.0.GA. This issue appeared while trying to upgrade an enterprise app from 4.2.1.GA to 5.0.0.GA. PersistenceUnitDeployment.java seems to be the culprit. Method calls to NonSerializableFactory.rebind() are made but to the variant of rebind() that won't auto-create the target context if necessary. This is a change of behavior from 4.2.1.GA. Another rebind() method is available with the argument createSubcontexts = true. If this method was used instead, backwards compatibility would be restored.