[JBoss JIRA] (WFLY-2102) Improve deployment annotation parsing error message
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2102:
-------------------------------
Fix Version/s: 8.0.1.Final
(was: 8.0.0.Final)
> Improve deployment annotation parsing error message
> -----------------------------------------------------
>
> Key: WFLY-2102
> URL: https://issues.jboss.org/browse/WFLY-2102
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: EE
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 8.0.1.Final
>
>
> Improve deployment annotation parsing error message
> Code such as this below, will error with IllegalArgumentException: Empty name segment is not allowed for env. The env is not enough information to identify what the issue is.
> @Singleton
> @Startup
> public class TestEJB {
> @Resource(name="/queue/test")
> private Queue queue;
> }
> Caused by: java.lang.IllegalArgumentException: Empty name segment is not allowed for env
> at org.jboss.msc.service.ServiceName.of(ServiceName.java:85) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceName.append(ServiceName.java:112) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.as.naming.deployment.ContextNames.buildServiceName(ContextNames.java:183)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:195)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo.<init>(ContextNames.java:186)
> at org.jboss.as.naming.deployment.ContextNames.bindInfoFor(ContextNames.java:141)
> at org.jboss.as.ee.component.OptionalLookupInjectionSource.getResourceValue(OptionalLookupInjectionSource.java:84)
> at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:1019)
> at org.jboss.as.ee.component.ComponentDescription$InjectedConfigurator.configureDependency(ComponentDescription.java:998)
> at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:138)
> at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:95)
> ... 6 more
--
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, 5 months
[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2387:
-------------------------------
Fix Version/s: 8.0.1.Final
(was: 8.0.0.Final)
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Fix For: 8.0.1.Final
>
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
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, 5 months
[JBoss JIRA] (WFLY-2275) StackOverflowError on DataSource resource injection
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2275?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2275:
-------------------------------
Fix Version/s: 8.0.1.Final
(was: 8.0.0.Final)
> StackOverflowError on DataSource resource injection
> ---------------------------------------------------
>
> Key: WFLY-2275
> URL: https://issues.jboss.org/browse/WFLY-2275
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Beta1
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 8.0.1.Final
>
> Attachments: standalone-osgi.xml
>
>
> {code}
> @Resource(name="java:comp/DefaultDataSource")
> public DataSource ds;
> {code}
> leads to
> {code}
> 10:59:21,901 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: resource-injection.jar:0.0.0
> 10:59:21,937 INFO [org.jboss.as.arquillian] (MSC service thread 1-3) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."resource-injection.jar",unit=resource-injection.jar,tests=[org.jboss.test.osgi.example.resource.ResourceInjectionTestCase]]
> 10:59:21,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."resource-injection.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."resource-injection.jar".Activate: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.StackOverflowError
> at java.util.Vector.<init>(Vector.java:127) [rt.jar:1.7.0_25]
> at java.util.Vector.<init>(Vector.java:144) [rt.jar:1.7.0_25]
> at java.util.Vector.<init>(Vector.java:153) [rt.jar:1.7.0_25]
> at javax.naming.NameImpl.<init>(NameImpl.java:273) [rt.jar:1.7.0_25]
> at javax.naming.NameImpl.<init>(NameImpl.java:277) [rt.jar:1.7.0_25]
> at javax.naming.CompositeName.<init>(CompositeName.java:231) [rt.jar:1.7.0_25]
> at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49)
> at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:496)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81)
> {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, 5 months
[JBoss JIRA] (WFLY-2480) Infinispan test XML files do not validate against XSD yet are parsed ok
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2480?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2480:
-------------------------------
Fix Version/s: 8.0.1.Final
(was: 8.0.0.Final)
> Infinispan test XML files do not validate against XSD yet are parsed ok
> -----------------------------------------------------------------------
>
> Key: WFLY-2480
> URL: https://issues.jboss.org/browse/WFLY-2480
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 8.0.1.Final
>
>
> So one or the other should to change.
> cvc-complex-type.2.4.a: Invalid content was found starting with element 'store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected.
> cvc-complex-type.2.4.a: Invalid content was found starting with element 'mixed-keyed-jdbc-store'. One of '{"urn:jboss:domain:infinispan:2.0":backups, "urn:jboss:domain:infinispan:2.0":backup-for}' is expected.
> cvc-complex-type.2.4.d: Invalid content was found starting with element 'binary-keyed-table'. No child element is expected at this point.
--
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, 5 months
[JBoss JIRA] (WFLY-2448) Print IOR to a user specified file
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2448?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2448:
-------------------------------
Fix Version/s: 8.0.1.Final
(was: 8.0.0.Final)
> Print IOR to a user specified file
> ----------------------------------
>
> Key: WFLY-2448
> URL: https://issues.jboss.org/browse/WFLY-2448
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: IIOP
> Affects Versions: 8.0.0.Beta1
> Environment: Windows, Solaris, Linux
> Reporter: Sumanth M S
> Assignee: Stefan Guilhen
> Priority: Minor
> Fix For: 8.0.1.Final
>
> Attachments: WFLY-2448.patch
>
>
> Jboss AS prints Corba IOR on console or log file. Many applications look for a file at a predefined location from where it can read the IOR; as it is difficult to read IOR programatically from a log file or console.
> An environment variable can be defined in standalone.conf to let the user specify the file location to which JBoss will print the IOR along with printing on the console.
> The solution has been tried and seems working. Please let us know if the solution can be submitted.
--
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, 5 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2426:
-------------------------------
Fix Version/s: 8.0.1.Final
(was: 8.0.0.Final)
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: build, integration, jbds, layers, version
> Fix For: 8.0.1.Final
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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, 5 months
[JBoss JIRA] (WFLY-2482) Enable/disable statistics for JCA deployments
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2482?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2482:
-------------------------------
Fix Version/s: 8.0.1.Final
(was: 8.0.0.Final)
> Enable/disable statistics for JCA deployments
> ---------------------------------------------
>
> Key: WFLY-2482
> URL: https://issues.jboss.org/browse/WFLY-2482
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JCA
> Reporter: Jesper Pedersen
> Assignee: Stefano Maestri
> Fix For: 8.0.1.Final
>
>
> Add operations to enable/disable statistics for JCA deployments.
> For datasources it would be
> {noformat}
> statistics=jdbc
> statistics=pool
> {noformat}
> For resource adapters it would be
> {noformat}
> statistics=pool
> {noformat}
> and all components that implement the statistics plugin extension
--
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, 5 months
[JBoss JIRA] (WFLY-2395) RootSubsystemOperationsTestCase fails if log directory wasn't properly cleaned
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2395?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2395:
-------------------------------
Fix Version/s: 8.0.1.Final
(was: 8.0.0.Final)
> RootSubsystemOperationsTestCase fails if log directory wasn't properly cleaned
> ------------------------------------------------------------------------------
>
> Key: WFLY-2395
> URL: https://issues.jboss.org/browse/WFLY-2395
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.1.Final
>
>
> Some test appears to not be cleaning up the {{target/logs}} directory which causes the tests to fail. While tests should be cleaning up after themselves, the test in the {{RootSubsystemOperationsTestCase}} should also not look for empty directories, but look for the files that _shouldn't_ be there.
> Files left behind:
> {code}
> [root@build01 logging]# ls -l target/logs/
> total 0
> -rw-r--r-- 1 root root 0 Oct 28 23:00 another.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 anotherProfile.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 fileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 profileFileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 server.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 sizeLogger.log
> {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, 5 months