[JBoss JIRA] (WFLY-2685) java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty"}}
by Luca Masini (JIRA)
Luca Masini created WFLY-2685:
---------------------------------
Summary: java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty"}}
Key: WFLY-2685
URL: https://issues.jboss.org/browse/WFLY-2685
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JPA / Hibernate
Affects Versions: 8.0.0.CR1
Environment: Mac OS 10.9
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
wildfly-8.0.0.CR1
Reporter: Luca Masini
Assignee: Scott Marlow
I have a regression from WF 8 Beta 1, I created a small test case that demostrate it.
In practice mapping an ElementCollection like this:
@ElementCollection(fetch = FetchType.EAGER)
@CollectionTable(name = "OUTPUTREQUEST_PREVWQUERYPRM")
@MapKeyJoinColumn(name = "param_id", referencedColumnName = "id")
Map<ParameterRegistry, String> previewQueryParams;
I got an exception during deployment:
Caused by: java.lang.IllegalStateException: Collection element (many-to-many) table alias cannot be empty
at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToManyJoin(LoadQueryJoinAndFetchProcessor.java:357) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderJoin(LoadQueryJoinAndFetchProcessor.java:154) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:137) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoin(LoadQueryJoinAndFetchProcessor.java:138) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:132) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.processQuerySpaceJoins(LoadQueryJoinAndFetchProcessor.java:113) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.plan.exec.internal.AbstractLoadQueryDetails.generate(AbstractLoadQueryDetails.java:171) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails.<init>(EntityLoadQueryDetails.java:106) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.plan.exec.internal.BatchingLoadQueryDetailsFactory.makeEntityLoadQueryDetails(BatchingLoadQueryDetailsFactory.java:73) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.<init>(AbstractLoadPlanBasedEntityLoader.java:100) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:134) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.entity.plan.EntityLoader.<init>(EntityLoader.java:55) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.entity.plan.EntityLoader$Builder.byUniqueKey(EntityLoader.java:98) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.entity.plan.EntityLoader$Builder.byPrimaryKey(EntityLoader.java:94) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.entity.plan.AbstractBatchingEntityLoaderBuilder.buildNonBatchingLoader(AbstractBatchingEntityLoaderBuilder.java:47) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.loader.entity.BatchingEntityLoaderBuilder.buildLoader(BatchingEntityLoaderBuilder.java:76) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2506) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2528) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.persister.entity.AbstractEntityPersister.createLoaders(AbstractEntityPersister.java:4029) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:4011) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:479) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:399) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.0.Final.jar:4.3.0.Final]
at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.0.Final.jar:]
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.0.0.CR1.jar:8.0.0.CR1]
... 8 more
I saw that is raised in the org.hibernate.loader.plan.exec.internal.LoadQueryJoinAndFetchProcessor.renderManyToOneJoin().
The same test-case work under
WF 8.0.0.Beta1
Glassfish 4
WebLogic 12c
--
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
[JBoss JIRA] (WFLY-2684) Security Domains not accessible throught web console
by Marko Mrvelj (JIRA)
[ https://issues.jboss.org/browse/WFLY-2684?page=com.atlassian.jira.plugin.... ]
Marko Mrvelj updated WFLY-2684:
-------------------------------
Description:
When trying to access Security Domains under Profile/Security tree, the call blocks. Tested on CentOS 6 and Windows 7 machine, and behaviour seems to be the same. Did not see problems with other parts of web console. Also security domains seem to be working when configured from CLI.
Also once you click on "Security Domain" the whole console stops responding to the mouse, and web refresh is needed to get it back.
On the same (Linux) machine this works in Beta1.
was:
When trying to access Security Domains under Profile/Security three, the call blocks. Tested on CentOS 6 and Windows 7 machine, and behaviour seems to be the same. Did not see problems with other parts of web console. Also security domains seem to be working when configured from CLI.
Also once you click on "Security Domain" the whole console stops responding to the mouse, and web refresh is needed to get it back.
On the same (Linux) machine this works in Beta1.
> Security Domains not accessible throught web console
> ----------------------------------------------------
>
> Key: WFLY-2684
> URL: https://issues.jboss.org/browse/WFLY-2684
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Console
> Affects Versions: 8.0.0.CR1
> Environment: Linux 2.6.32-358.23.2.el6.x86_64 (CentOS 6.4) with 1.7.0_45-mockbuild_2013_10_23_08_18-b00 (OpenJDK 7) or Windows 7 64bit with Oracle Java 7
> Reporter: Marko Mrvelj
> Assignee: Heiko Braun
>
> When trying to access Security Domains under Profile/Security tree, the call blocks. Tested on CentOS 6 and Windows 7 machine, and behaviour seems to be the same. Did not see problems with other parts of web console. Also security domains seem to be working when configured from CLI.
> Also once you click on "Security Domain" the whole console stops responding to the mouse, and web refresh is needed to get it back.
> On the same (Linux) machine this works in Beta1.
--
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
[JBoss JIRA] (WFLY-2684) Security Domains not accessible throught web console
by Marko Mrvelj (JIRA)
Marko Mrvelj created WFLY-2684:
----------------------------------
Summary: Security Domains not accessible throught web console
Key: WFLY-2684
URL: https://issues.jboss.org/browse/WFLY-2684
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Console
Affects Versions: 8.0.0.CR1
Environment: Linux 2.6.32-358.23.2.el6.x86_64 (CentOS 6.4) with 1.7.0_45-mockbuild_2013_10_23_08_18-b00 (OpenJDK 7) or Windows 7 64bit with Oracle Java 7
Reporter: Marko Mrvelj
Assignee: Heiko Braun
When trying to access Security Domains under Profile/Security three, the call blocks. Tested on CentOS 6 and Windows 7 machine, and behaviour seems to be the same. Did not see problems with other parts of web console. Also security domains seem to be working when configured from CLI.
Also once you click on "Security Domain" the whole console stops responding to the mouse, and web refresh is needed to get it back.
On the same (Linux) machine this works in Beta1.
--
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
[JBoss JIRA] (WFLY-2645) SFSB containing injected DataSource fails to passivate/serialize
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-2645?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-2645:
------------------------------------
[~jesper.pedersen] No - this is a WF bug. If this can be addressed within the context of ironjacamar, great - but please open a separate jira and link it here. IMO, this is more appropriate addressed by the connector subsystem, which should use a serializable proxy to the DataSource from ironjacamar. This is what we do for other EE resources.
> SFSB containing injected DataSource fails to passivate/serialize
> ----------------------------------------------------------------
>
> Key: WFLY-2645
> URL: https://issues.jboss.org/browse/WFLY-2645
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: Paul Ferraro
> Assignee: Stefano Maestri
> Priority: Critical
>
> See JBPAPP6-1762 for details.
--
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
[JBoss JIRA] (WFLY-2679) Jdbc cache store couldn't read databaseType property
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-2679?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-2679:
-------------------------------
Fix Version/s: 8.0.0.Final
> Jdbc cache store couldn't read databaseType property
> ----------------------------------------------------
>
> Key: WFLY-2679
> URL: https://issues.jboss.org/browse/WFLY-2679
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Environment: WildFly 8.0.0.Beta2-SNAPSHOT (from 2013-12-16
> Reporter: Tomas Remes
> Assignee: Paul Ferraro
> Fix For: 8.0.0.Final
>
>
> If you want use some driver, which type is not recognizable by Infinispan (e.g. jtds driver), then you are asked to specify your DB type via "databaseType" property in your cache store configuration. But when you specify it, you'll get following exception:
> {noformat}
> org.infinispan.commons.CacheConfigurationException: Couldn't find a setter named [setDatabaseType] which takes a single parameter, for parameter databaseType on class [class org.infinispan.persistence.jdbc.configuration.JdbcBinaryStoreConfigurationBuilder]
> at org.infinispan.configuration.parsing.XmlConfigHelper.setValues(XmlConfigHelper.java:450)
> at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:91)
> at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:9)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.processModelNode(CacheAdd.java:542)
> at org.jboss.as.clustering.infinispan.subsystem.ClusteredCacheAdd.processModelNode(ClusteredCacheAdd.java:69)
> at org.jboss.as.clustering.infinispan.subsystem.SharedStateCacheAdd.processModelNode(SharedStateCacheAdd.java:50)
> at org.jboss.as.clustering.infinispan.subsystem.DistributedCacheAdd.processModelNode(DistributedCacheAdd.java:90)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.installRuntimeServices(CacheAdd.java:205)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.performRuntime(CacheAdd.java:179)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:343) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {noformat}
--
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
[JBoss JIRA] (WFLY-334) HA Singleton deployer for applications
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-334?page=com.atlassian.jira.plugin.s... ]
Paul Ferraro updated WFLY-334:
------------------------------
Comment: was deleted
(was: Good day,
I am on leave and will return to the office on Monday, 6 January 2014. For any urgent matters log a support ticket with support(a)nha.co.za or at telephone 0860142536.
Kind Regards
Nico Schlebusch
The e-mail and attachments are confidential and intended only for selected recipients. If you have received it in error, you may not in any way disclose or rely on the contents. You
may not keep, copy or distribute the e-mail. Should you receive it, immediately notify the sender of the error and delete the e-mail. Also note that this form of communication is
not secure, it can be intercepted, and may not necessarily be free of errors and viruses in spite of reasonable efforts to secure this medium.
)
> HA Singleton deployer for applications
> --------------------------------------
>
> Key: WFLY-334
> URL: https://issues.jboss.org/browse/WFLY-334
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering, Domain Management
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Labels: deployers, hasingleton
> Fix For: 8.0.0.Final
>
>
> A HASingleton deployer should be provided in standalone and domain mode.
> To be able to migrate such singleton applications from former AS versions.
--
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
[JBoss JIRA] (WFLY-334) HA Singleton deployer for applications
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-334?page=com.atlassian.jira.plugin.s... ]
Paul Ferraro updated WFLY-334:
------------------------------
Comment: was deleted
(was: Sehr geehrte Damen und Herren, von Montag, den 23.12.2013, bis einschließlich Freitag, den 10.01.2014, bin ich nicht im Hause. In dringenden Fällen wenden Sie sich bitte an Heiner Tittelbach (IT 271) oder Bernd Kirchgäßner (IT 221). Ihre Mail wird nicht automatisch weitergeleitet. Mit freundlichen Grüßen Jochen Riedlinger
)
> HA Singleton deployer for applications
> --------------------------------------
>
> Key: WFLY-334
> URL: https://issues.jboss.org/browse/WFLY-334
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering, Domain Management
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Labels: deployers, hasingleton
> Fix For: 8.0.0.Final
>
>
> A HASingleton deployer should be provided in standalone and domain mode.
> To be able to migrate such singleton applications from former AS versions.
--
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
[JBoss JIRA] (WFLY-2679) Jdbc cache store couldn't read databaseType property
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-2679?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-2679:
------------------------------------
databaseType is not a property of the jdbc cache stores, but a property of the "TableManipulation" configuration bean. We should expose this as an explicit attribute.
> Jdbc cache store couldn't read databaseType property
> ----------------------------------------------------
>
> Key: WFLY-2679
> URL: https://issues.jboss.org/browse/WFLY-2679
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Environment: WildFly 8.0.0.Beta2-SNAPSHOT (from 2013-12-16
> Reporter: Tomas Remes
> Assignee: Paul Ferraro
>
> If you want use some driver, which type is not recognizable by Infinispan (e.g. jtds driver), then you are asked to specify your DB type via "databaseType" property in your cache store configuration. But when you specify it, you'll get following exception:
> {noformat}
> org.infinispan.commons.CacheConfigurationException: Couldn't find a setter named [setDatabaseType] which takes a single parameter, for parameter databaseType on class [class org.infinispan.persistence.jdbc.configuration.JdbcBinaryStoreConfigurationBuilder]
> at org.infinispan.configuration.parsing.XmlConfigHelper.setValues(XmlConfigHelper.java:450)
> at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:91)
> at org.infinispan.configuration.cache.AbstractStoreConfigurationBuilder.withProperties(AbstractStoreConfigurationBuilder.java:9)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.processModelNode(CacheAdd.java:542)
> at org.jboss.as.clustering.infinispan.subsystem.ClusteredCacheAdd.processModelNode(ClusteredCacheAdd.java:69)
> at org.jboss.as.clustering.infinispan.subsystem.SharedStateCacheAdd.processModelNode(SharedStateCacheAdd.java:50)
> at org.jboss.as.clustering.infinispan.subsystem.DistributedCacheAdd.processModelNode(DistributedCacheAdd.java:90)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.installRuntimeServices(CacheAdd.java:205)
> at org.jboss.as.clustering.infinispan.subsystem.CacheAdd.performRuntime(CacheAdd.java:179)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:343) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {noformat}
--
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
[JBoss JIRA] (WFLY-2680) java:comp/DefaultDataSource doesn't work in persistence.xml
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-2680?page=com.atlassian.jira.plugin.... ]
arjan tijms commented on WFLY-2680:
-----------------------------------
{quote}The reason why this does not work is because java:comp is scoped to a component{quote}
You're right, and this is perhaps a somewhat unfortunate choice. Perhaps {{java:app}} of even {{java:global}} would have been the better choice. I've always thought of {{java:comp}} to be a somewhat peculiar space anyway, as the entire web module counts as one component, but every single EJB bean is a component as well. With the EJB model being slowly retrofitted towards a set of CDI extensions and interceptors it's not clear to me what the long term usage of this name space will be anyway.
I guess {{java:comp}} was chosen so it can be more easily re-mapped to another data source on a per component basis, but not sure if that's worth the hassle.
Note that all the other default resources, like the JMS connection factory and executor service and such are also in {{java:comp}}.
{quote}We can probably just hack something in to make this work though, as it would be more user friendly.{quote}
That would be really great! I'll try to address this issue with the EG and ask for some clarification.
> java:comp/DefaultDataSource doesn't work in persistence.xml
> -----------------------------------------------------------
>
> Key: WFLY-2680
> URL: https://issues.jboss.org/browse/WFLY-2680
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: EE, JPA / Hibernate
> Affects Versions: 8.0.0.CR1
> Reporter: arjan tijms
> Assignee: David Lloyd
> Labels: javaee7, jdbc
>
> Having a persistence.xml with the following content fails the deployment on WildFly 8 CR1:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <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://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
>
> <persistence-unit name="testPU">
> <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
> </persistence-unit>
> </persistence>
> {code}
> It results in the following error:
> {noformat}
> 13:51:40,367 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "dynamic-named-query.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"dynamic-named-query.war#testPU\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.dynamic-named-query.dynamic-named-query.DefaultDataSource]"]}
> {noformat}
> When I proposed the feature for the default data source over at the Java EE JIRA (https://java.net/jira/browse/JAVAEE_SPEC-4) I intended this to work. In the description I hinted that the standard JNDI name would be the standard alternative for {{java:jboss/datasources/ExampleDS}} on JBoss. The latter indeed does work in {{persistence.xml}} using WildFly 8 CR1.
> Omitting the {{jta-data-source}} element altogether *does* work, which is great. However, I foresee a lot of users tripping over this in the future and just giving up the idea of using a default data source, especially since the error message is very cryptic for new developers.
> In GlassFish 4 using {{java:comp/DefaultDataSource}} in {{persistence.xml}} does work.
> See also WFLY-2027 and 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
[JBoss JIRA] (JBASM-38) shutdown the second time throw stack trace to the console
by Shelly McGowan (JIRA)
[ https://issues.jboss.org/browse/JBASM-38?page=com.atlassian.jira.plugin.s... ]
Shelly McGowan commented on JBASM-38:
-------------------------------------
this may be related to the changes as seen in https://issues.jboss.org/browse/JBAS-7818 which impacted shutdown.
See:
https://issues.jboss.org/browse/JBAS-7889
specifically:
https://community.jboss.org/wiki/StartAndStopTheJBossApplicationServer
> shutdown the second time throw stack trace to the console
> ---------------------------------------------------------
>
> Key: JBASM-38
> URL: https://issues.jboss.org/browse/JBASM-38
> Project: JBoss AS Server Manager
> Issue Type: Enhancement
> Environment: JBossAS 6.0.0.Final "Neo", Windows 7
> Reporter: Larry Chan
> Assignee: Shelly McGowan
> Priority: Minor
>
> I'm filing for my coworker who doesn't have an account here.
> shutdown.bat -o 16.89.22.157
> Exception in thread "main" java.io.IOException: Failed to retrieve RMIServer stu
> b: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectE
> xception: Connection refused to host: 16.89.22.157; nested exception is:
> java.net.ConnectException: Connection refused: connect]
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:33
> 8)
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFacto
> ry.java:248)
> at org.jboss.Shutdown.main(Shutdown.java:235)
> Caused by: javax.naming.ServiceUnavailableException [Root exception is java.rmi.
> ConnectException: Connection refused to host: 16.89.22.157; nested exception is:
> java.net.ConnectException: Connection refused: connect]
> at com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java
> :101)
> at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.j
> ava:185)
> at javax.naming.InitialContext.lookup(InitialContext.java:392)
> at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnect
> or.java:1886)
> at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.j
> ava:1856)
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:25
> 7)
> ... 2 more
> Caused by: java.rmi.ConnectException: Connection refused to host: 16.89.22.157;
> nested exception is:
> java.net.ConnectException: Connection refused: connect
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601)
> at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198
> )
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
> at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
> at com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java
> :97)
> ... 7 more
> Caused by: java.net.ConnectException: Connection refused: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at java.net.Socket.connect(Socket.java:478)
> at java.net.Socket.<init>(Socket.java:375)
> at java.net.Socket.<init>(Socket.java:189)
> at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirect
> SocketFactory.java:22)
> at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMaster
> SocketFactory.java:128)
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
> ... 12 more
> Press any key to continue . . .
> EXPECTED BEHAVIOR:
> It is better and more standard just output message of "already shutdown".
--
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