October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2027) EE Default DataSource is not working

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.... ] Eduardo Martins reassigned WFLY-2027: ------------------------------------- Assignee: Eduardo Martins > EE Default DataSource is not working > ------------------------------------ > > Key: WFLY-2027 > URL: https://issues.jboss.org/browse/WFLY-2027 > Project: WildFly > Issue Type: Bug > Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console > Affects Versions: 8.0.0.Alpha4 > Reporter: Lincoln Baxter III > Assignee: Eduardo Martins > > The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed: > {code}EE 5.19 > The Java EE Platform requires that a Java EE Product Provider provide a database > in the operational environment (see Section EE.2.6, “Database”). The Java EE > Product Provider must also provide a preconfigured, default data source for use by > the application in accessing this database. > The Java EE Product Provider must make the default data source accessible to > the application under the JNDI name java:comp/DefaultDataSource. > The Application Component Provider or Deployer may explicitly bind a > DataSource resource reference to the default data source using the lookup element > of the Resource annotation or the lookup-name element of the resource-ref > deployment descriptor element. For example, > @Resource(lookup="java:comp/DefaultDataSource") > DataSource myDS; > In the absence of such a binding, the mapping of the reference will default to > the product's default data source. > For example, the following will map to a preconfigured data source for the > product's default database: > @Resource > DataSource myDS;{code} > This, isn't working however: > {code} > <persistence version="2.1" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persis..."> > <persistence-unit name="default" transaction-type="JTA"> > </persistence-unit> > </persistence>{code} > Results in: > {code} > 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final] > Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set > at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98) > at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66) > at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193) > at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88) > at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159) > at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131) > at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836) > at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835) > at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4] > ... 4 more > 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set > Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}} > {code} > Additionally, actually specifying the expected JDNI name of the default DS like this: > {code} <persistence-unit name="default" transaction-type="JTA"> > <jta-data-source>java:comp/DefaultDataSource</jta-data-source> > <exclude-unlisted-classes>false</exclude-unlisted-classes> > </persistence-unit>{code} > Results in this: > {code} > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] > service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2185) Get core model test framework working with 7.2.0.Final legacy controller

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2185: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015245 > Get core model test framework working with 7.2.0.Final legacy controller > ------------------------------------------------------------------------ > > Key: WFLY-2185 > URL: https://issues.jboss.org/browse/WFLY-2185 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2172) Resurrect the mixed domain testing and fix any problems

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2172: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015243 > Resurrect the mixed domain testing and fix any problems > ------------------------------------------------------- > > Key: WFLY-2172 > URL: https://issues.jboss.org/browse/WFLY-2172 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 8.0.0.CR1 > > > THis has not been run for quite some time, and needs to be included in the general testing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-283) SegmentMemory staged LeftTuples not always accessed correctly

by Mark Proctor (JIRA)

Mark Proctor created DROOLS-283: ----------------------------------- Summary: SegmentMemory staged LeftTuples not always accessed correctly Key: DROOLS-283 URL: https://issues.jboss.org/browse/DROOLS-283 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor Some times it accesses the current staging list, instead of the one in the segment memory. The NotNode should use the passed staging list, and not retrieve it directly. They should always use takeAll, to ensure they are thread safe. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1979) Default EE default bindings per-deployment

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-1979?page=com.atlassian.jira.plugin.... ] Eduardo Martins updated WFLY-1979: ---------------------------------- Summary: Default EE default bindings per-deployment (was: Default EE Concurrent per-deployment) > Default EE default bindings per-deployment > ------------------------------------------ > > Key: WFLY-1979 > URL: https://issues.jboss.org/browse/WFLY-1979 > Project: WildFly > Issue Type: Feature Request > Components: EE > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > Deployments/Components should have the possibility of overriding what EE Concurrent (JSR-236) default resources it has in JNDI, for instance, instead of having the globally shared managed executor service, a component could use its "jboss" deployment descriptor to have a different executor at java:comp/DefaultManagedExecutorService. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1979) Default EE default bindings per-deployment

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-1979?page=com.atlassian.jira.plugin.... ] Eduardo Martins updated WFLY-1979: ---------------------------------- Description: Deployments/Components should have the possibility of overriding what EE default bindings, introduced by WFLY-2158. was: Deployments/Components should have the possibility of overriding what EE Concurrent (JSR-236) default resources it has in JNDI, for instance, instead of having the globally shared managed executor service, a component could use its "jboss" deployment descriptor to have a different executor at java:comp/DefaultManagedExecutorService. > Default EE default bindings per-deployment > ------------------------------------------ > > Key: WFLY-1979 > URL: https://issues.jboss.org/browse/WFLY-1979 > Project: WildFly > Issue Type: Feature Request > Components: EE > Reporter: Eduardo Martins > Assignee: Eduardo Martins > > Deployments/Components should have the possibility of overriding what EE default bindings, introduced by WFLY-2158. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2206) Manualmode test suite copes the modules directory multiple times

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2206?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-2206. ------------------------------- Assignee: Stuart Douglas (was: Tomaz Cerar) Fix Version/s: 8.0.0.Beta1 Resolution: Done > Manualmode test suite copes the modules directory multiple times > ---------------------------------------------------------------- > > Key: WFLY-2206 > URL: https://issues.jboss.org/browse/WFLY-2206 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.Beta1 > > > This uses lots of disk space for no good reason -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-282) Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context

by Marco Rietveld (JIRA)

[ https://issues.jboss.org/browse/DROOLS-282?page=com.atlassian.jira.plugin... ] Marco Rietveld updated DROOLS-282: ---------------------------------- Attachment: app-scoped-em-race-condition-example.txt Added a stack trace that illustrates the race-condition. > Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context > ------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-282 > URL: https://issues.jboss.org/browse/DROOLS-282 > Project: Drools > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final > Reporter: Marco Rietveld > Assignee: Marco Rietveld > Attachments: app-scoped-em-race-condition-example.txt > > > The application scoped persistence context ({{EntityManager}}) causes a race-condition when a persistence KieSession is accessed by multiple threads in which the transaction is _*not*_ managed by the {{KieSession}} but by code outside of the drools/jbpm/kie code base. > A "{{CommandSessionCommandService}}" implementation would work very similarly to the existing {{SingleSessionCommandService}} implementation: in both implementations, each thread would use it's own command scoped entity manager. > However, the {{CommandSessionCommandService}} would *not* use an {{EntityManager}} that would be used by multiple threads. > The race-condition that arises due to the use of an application scoped entity manager is due to the following: > - The JPA spec clearly states that the {{EntityManager}} is not thread-safe. > - As a result of this Hibernate (and probably other ORM frameworks) only has one internal object to represent whether or not the {{EntityManager(Impl)}} has joined a transaction or not. > - For JTA, Hibernate uses the JTA Synchronization mechanism (normal, not interposed) in order to reset this status once a transaction has committed. > - When one thread calls {{tx.commit()}} while another thread calls {{em.joinTransaction()}}, then a race-condition can happen in which the "joined transaction" status is first set by the {{EntityManager.joinTransaction()}} call _after which the status is reset to *not-joined* by the Hibernate injected JTA Synchronization instance in it's {{afterCompletion(..)}} method)_. > Occasionally, the call to {{EntityManager.joinTransaction()}} will fail because of this race-condtion, although the more dangerous situation is one in which {{.joinTransaction()}} does not throw an exception but where the race-condition does happen. > I've made a trivial effort to create this implementation and discovered that it's more difficult than I had initially expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2176) JSF should be able to access the CDI-enabled ValidatorFactory

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-2176?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-2176: ---------------------------------- Created the following pull request: https://github.com/wildfly/wildfly/pull/5212 > JSF should be able to access the CDI-enabled ValidatorFactory > ------------------------------------------------------------- > > Key: WFLY-2176 > URL: https://issues.jboss.org/browse/WFLY-2176 > Project: WildFly > Issue Type: Feature Request > Components: JSF > Affects Versions: 8.0.0.Alpha4 > Reporter: Farah Juma > Assignee: Farah Juma > > Currently, for every deployment that uses JSF, the JSF subsystem adds the org.hibernate.validator module to the deployment. A ValidatorFactory is then obtained via the standard Bean Validation bootstrap strategy. However, a ValidatorFactory obtained this way isn't CDI-enabled. JSF needs to use the EE LazyValidatorFactory instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-282) Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context

by Marco Rietveld (JIRA)

Marco Rietveld created DROOLS-282: ------------------------------------- Summary: Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context Key: DROOLS-282 URL: https://issues.jboss.org/browse/DROOLS-282 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Final Reporter: Marco Rietveld Assignee: Marco Rietveld The application scoped persistence context ({{EntityManager}}) causes a race-condition when a persistence KieSession is accessed by multiple threads in which the transaction is _*not*_ managed by the {{KieSession}} but by code outside of the drools/jbpm/kie code base. A "{{CommandSessionCommandService}}" implementation would work very similarly to the existing {{SingleSessionCommandService}} implementation: in both implementations, each thread would use it's own command scoped entity manager. However, the {{CommandSessionCommandService}} would *not* use an {{EntityManager}} that would be used by multiple threads. The race-condition that arises due to the use of an application scoped entity manager is due to the following: - The JPA spec clearly states that the {{EntityManager}} is not thread-safe. - As a result of this Hibernate (and probably other ORM frameworks) only has one internal object to represent whether or not the {{EntityManager(Impl)}} has joined a transaction or not. - For JTA, Hibernate uses the JTA Synchronization mechanism (normal, not interposed) in order to reset this status once a transaction has committed. - When one thread calls {{tx.commit()}} while another thread calls {{em.joinTransaction()}}, then a race-condition can happen in which the "joined transaction" status is first set by the {{EntityManager.joinTransaction()}} call _after which the status is reset to *not-joined* by the Hibernate injected JTA Synchronization instance in it's {{afterCompletion(..)}} method)_. Occasionally, the call to {{EntityManager.joinTransaction()}} will fail because of this race-condtion, although the more dangerous situation is one in which {{.joinTransaction()}} does not throw an exception but where the race-condition does happen. I've made a trivial effort to create this implementation and discovered that it's more difficult than I had initially expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2013