March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3966) Allow soapFaults to be returned for HTTP_BAD_REQUEST are per SOAP 1.2 spec

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3966?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3966: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1151526|https://bugzilla.redhat.com/show_bug.cgi?id=1151526] from ASSIGNED to ON_QA > Allow soapFaults to be returned for HTTP_BAD_REQUEST are per SOAP 1.2 spec > -------------------------------------------------------------------------- > > Key: WFLY-3966 > URL: https://issues.jboss.org/browse/WFLY-3966 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Mustafa Musaji > Assignee: Bartosz Baranowski > Attachments: SAAJ-74.patch > > > SOAP 1.2 spec says that HTTP 400 should return a soapFault error. At the moment the code only returns SoapFault for HTTP 500 which is wrong. > The issue is recorded in the SAAJ JIRA: https://java.net/jira/browse/SAAJ-74 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-604) After failed to deploy, remain deployment information in JBOSS_HOME/{standalone|domaine}/data/content directory

by Chao Wang (JIRA)

Chao Wang created WFCORE-604: -------------------------------- Summary: After failed to deploy, remain deployment information in JBOSS_HOME/{standalone|domaine}/data/content directory Key: WFCORE-604 URL: https://issues.jboss.org/browse/WFCORE-604 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha19 Reporter: Chao Wang Assignee: Chao Wang {noformat} Description of problem: === - After failed to deploy, remain deployment information in JBOSS_HOME/{standalone|domaine}/data/content directory - Please see following reproduce steps. How reproducible: === Steps to Reproduce: 1. Fail to deploy application via jboss-cli 2. Find deployment info in JBOSS_HOME/{standalone|domaine}/data/content, but there are no standalone.xml in <deployments> tag. 3. Fix deployment and success to deploy. 4. Find "new" deployment info in JBOSS_HOME/{standalone|domaine}/data/content, and the old deployment info will be still there. - I know that as we changed application in step-3, its hash value was changed. And then, old info is remained in JBOSS_HOME/{standalone|domaine}/data/content. But I think it always happens and should be fixed. Actual results: - The deployment information which created when deploy was failed remains in JBOSS_HOME/{standalone|domaine}/data/content. Expected results: - The deployment information which created when deploy was failed should be removed if the deploy is failed. {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3886) add org.jboss.remote-naming dep to org.hornetq.ra module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3886?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3886: ----------------------------------------------- Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1202440|https://bugzilla.redhat.com/show_bug.cgi?id=1202440] from NEW to ASSIGNED > add org.jboss.remote-naming dep to org.hornetq.ra module > -------------------------------------------------------- > > Key: WFLY-3886 > URL: https://issues.jboss.org/browse/WFLY-3886 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Add an optional dependency to org.jboss.remote-naming to the org.hornetq.ra to be able to create a RA that connects to a remote hornetq-server. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4303) Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4303?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4303: ----------------------------------------------- wfink(a)redhat.com changed the Status of [bug 1194381|https://bugzilla.redhat.com/show_bug.cgi?id=1194381] from ASSIGNED to MODIFIED > Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-4303 > URL: https://issues.jboss.org/browse/WFLY-4303 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: Tomasz Adamski > Fix For: 9.0.0.Beta1 > > > Applications need to have a jboss-ejb-client.xml configuration to use connections to other WildFly servers. > The remote-outbound-connection allow expressions, i.e. for user-name. > But if a cluster come into play the related <cluster> element inside the jboss-ejb-client.xml must have the same username and this can be only hardcoded. > So the jboss-ejb-client.xml parsing should allow expressions for > outbound-connection-ref, username, security-realm etc. > See https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-ma... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3886) add org.jboss.remote-naming dep to org.hornetq.ra module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3886?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3886: ----------------------------------------------- Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1202441|https://bugzilla.redhat.com/show_bug.cgi?id=1202441] from NEW to ASSIGNED > add org.jboss.remote-naming dep to org.hornetq.ra module > -------------------------------------------------------- > > Key: WFLY-3886 > URL: https://issues.jboss.org/browse/WFLY-3886 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.CR1 > > > Add an optional dependency to org.jboss.remote-naming to the org.hornetq.ra to be able to create a RA that connects to a remote hornetq-server. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4440) CLI: Log or store results (ModelNode) in batch commands

by Martin Basovnik (JIRA)

[ https://issues.jboss.org/browse/WFLY-4440?page=com.atlassian.jira.plugin.... ] Martin Basovnik commented on WFLY-4440: --------------------------------------- Is there any reason why {{CommandContextImpl}} class is package-private and not public? > CLI: Log or store results (ModelNode) in batch commands > ------------------------------------------------------- > > Key: WFLY-4440 > URL: https://issues.jboss.org/browse/WFLY-4440 > Project: WildFly > Issue Type: Bug > Components: CLI > Reporter: Martin Basovnik > Assignee: Alexey Loubyansky > Labels: cli, log > > Non-batch commands are logged with method {{ctx.printLine(result.toString());}} > https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/java/org... > Log also batch commands, e.g. > https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/java/org... > Or use a mechanism to store the last result. I use your API and it would be usefull for me. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-263: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1202610|https://bugzilla.redhat.com/show_bug.cgi?id=1202610] from NEW to ASSIGNED > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > Attachments: unundeployable.zip > > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-489) The "access-mechanism" field in the active-operation resources is always undefined

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-489?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-489: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1202610|https://bugzilla.redhat.com/show_bug.cgi?id=1202610] from NEW to ASSIGNED > The "access-mechanism" field in the active-operation resources is always undefined > ---------------------------------------------------------------------------------- > > Key: WFCORE-489 > URL: https://issues.jboss.org/browse/WFCORE-489 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha15 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 1.0.0.Beta1 > > > The "access-mechanism" field in core-service=management/service=active-operations/active-operation=* is always undefined. The code that sets it is using the wrong var: > {code} > ModelNode accessMechanismNode = model.get(ACCESS_MECHANISM); > if (accessMechanism != null) { > accessMechanismNode.set(accessMechanismNode.toString()); > } > {code} > It should be accessMechanism.toString() -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4440) CLI: Log or store results (ModelNode) in batch commands

by Martin Basovnik (JIRA)

Martin Basovnik created WFLY-4440: ------------------------------------- Summary: CLI: Log or store results (ModelNode) in batch commands Key: WFLY-4440 URL: https://issues.jboss.org/browse/WFLY-4440 Project: WildFly Issue Type: Bug Components: CLI Reporter: Martin Basovnik Assignee: Alexey Loubyansky Non-batch commands are logged with method {{ctx.printLine(result.toString());}} https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/java/org... Log also batch commands, e.g. https://github.com/wildfly/wildfly-core/blob/master/cli/src/main/java/org... Or use a mechanism to store the last result. I use your API and it would be usefull for me. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ] Tomas Remes commented on WFLY-2387: ----------------------------------- Yes but it's basically Matus's test applied to actual master. Nothing more. Here it is https://github.com/tremes/wildfly/tree/WFLY-2387-test > 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.Beta1 > > 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, 4 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 March 2015