[JBoss JIRA] (WFLY-2100) Vault.sh logging improvements
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2100?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2100:
-------------------------------
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Vault.sh logging improvements
> -----------------------------
>
> Key: WFLY-2100
> URL: https://issues.jboss.org/browse/WFLY-2100
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 8.0.0.Alpha4
> Reporter: Chris Dolphy
> Assignee: Peter Skopek
> Fix For: 9.0.0.CR1
>
>
> Several errors with vault.sh (ineractive Vault Tool) do not display enough information to debug.
> For example, "Exception occurred:PBOX000128: Unable to encrypt data". It would be nice if there was some way to see the cause of this exception either with additional logging options, a verbose option or by default. This one is caused by VaultInteraction.java only displaying the localized error message of the exception.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[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: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Improve deployment annotation parsing error message
> -----------------------------------------------------
>
> Key: WFLY-2102
> URL: https://issues.jboss.org/browse/WFLY-2102
> Project: WildFly
> Issue Type: Enhancement
> Components: EE
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.CR1
>
>
> 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 was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 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: 9.0.0.CR1
(was: 9.0.0.Beta1)
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Fix For: 9.0.0.CR1
>
> 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 was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-2422) Simplify the remote-outbound connections
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2422:
-------------------------------
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Simplify the remote-outbound connections
> ----------------------------------------
>
> Key: WFLY-2422
> URL: https://issues.jboss.org/browse/WFLY-2422
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB, Remoting
> Affects Versions: 8.0.0.Beta1
> Reporter: Wolf-Dieter Fink
> Assignee: Tomasz Adamski
> Fix For: 9.0.0.CR1
>
>
> At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml.
> But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster.
> It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration.
> In this case it is possible to keep the application deployment independent from the server environment.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 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: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Print IOR to a user specified file
> ----------------------------------
>
> Key: WFLY-2448
> URL: https://issues.jboss.org/browse/WFLY-2448
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP
> Affects Versions: 8.0.0.Beta1
> Environment: Windows, Solaris, Linux
> Reporter: Sumanth M S
> Assignee: Stefan Guilhen
> Priority: Minor
> Fix For: 9.0.0.CR1
>
> 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 was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-2440) Thread pool AccessControlContext Propagation
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2440?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2440:
-------------------------------
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Thread pool AccessControlContext Propagation
> --------------------------------------------
>
> Key: WFLY-2440
> URL: https://issues.jboss.org/browse/WFLY-2440
> Project: WildFly
> Issue Type: Task
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.CR1
>
>
> A decision was made within Java that newly created threads should inherit the access control context of their creator.
> In general this was justified on the basis that if you are creating a thread you want it to inherit the permissions you already have.
> Once we introduce thread pooling that logic no longer makes as much sense and there is not the same relationship between the thread that triggers it's creation and the long term life of that thread.
> This may affect components outside of WildFly but I am raising it here as a top level task.
> Should also note that JBoss Threads does already have some protection built in if a security manager is in use but there are times the AccessControlContext will be used without a security manager so more control is required.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 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: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: build, integration, jbds, layers, version
> Fix For: 9.0.0.CR1
>
>
> 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 was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-2484) Revise clustering tests
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-2484?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-2484:
-------------------------------
Fix Version/s: 9.0.0.CR1
(was: 9.0.0.Beta1)
> Revise clustering tests
> -----------------------
>
> Key: WFLY-2484
> URL: https://issues.jboss.org/browse/WFLY-2484
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 9.0.0.CR1
>
>
> Paul pointed out that some of the tests are no longer relevant with the new implementation and some were never actually relevant, e.g. duplicate tests.
> We should revise the set of tests to keep the testsuite small and find out missing tests.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months