February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1392) Undeploy doesn't remove Data content if server is in --admin-only mode

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1392?page=com.atlassian.jira.plugi... ] Chao Wang commented on WFCORE-1392: ----------------------------------- Hi [~brian.stansberry] Can we safely remove _*if (context.isNormalServer())*_ condition inside DeploymentRemoveHandler ? I noticed other handlers don't contain this at the beginning of method execute() such as DeploymentAddHandler, DeploymentDeployHandler and DeploymentUndeployHandler which explains why only remove action does not work in admin-only mode. > Undeploy doesn't remove Data content if server is in --admin-only mode > ----------------------------------------------------------------------- > > Key: WFCORE-1392 > URL: https://issues.jboss.org/browse/WFCORE-1392 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 2.1.0.CR2 > Reporter: Chao Wang > Assignee: Jason Greene > > {noformat} > Steps to Reproduce: > 1. Start server instance using --admin-only flag > 2. Deploy application using CLI command. > ~~~ > deploy /valid/path/WebApp.war --runtime-name=WebApp.war --name=WebApp.war > ~~~ > 3. Undeploy application using CLI command: > ~~~ > undeploy WebApp.war > ~~~ > 4. Application will be undeployed but content from 'data' directory are not removed. > {noformat} > Lines: > https://github.com/wildfly/wildfly-core/blob/b1a4439f442f7984e681840c0f8d... > https://github.com/wildfly/wildfly-core/blob/e737eff554ee433ca54835154fd6... > runningMode value is ADMIN_ONLY will bypass that step in DeploymentRemoveHandler.java leads to this behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1392) Undeploy doesn't remove Data content if server is in --admin-only mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1392?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration updated WFCORE-1392: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1308841 Bugzilla Update: Perform > Undeploy doesn't remove Data content if server is in --admin-only mode > ----------------------------------------------------------------------- > > Key: WFCORE-1392 > URL: https://issues.jboss.org/browse/WFCORE-1392 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 2.1.0.CR2 > Reporter: Chao Wang > Assignee: Jason Greene > > {noformat} > Steps to Reproduce: > 1. Start server instance using --admin-only flag > 2. Deploy application using CLI command. > ~~~ > deploy /valid/path/WebApp.war --runtime-name=WebApp.war --name=WebApp.war > ~~~ > 3. Undeploy application using CLI command: > ~~~ > undeploy WebApp.war > ~~~ > 4. Application will be undeployed but content from 'data' directory are not removed. > {noformat} > Lines: > https://github.com/wildfly/wildfly-core/blob/b1a4439f442f7984e681840c0f8d... > https://github.com/wildfly/wildfly-core/blob/e737eff554ee433ca54835154fd6... > runningMode value is ADMIN_ONLY will bypass that step in DeploymentRemoveHandler.java leads to this behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1392) Undeploy doesn't remove Data content if server is in --admin-only mode

by Chao Wang (JIRA)

Chao Wang created WFCORE-1392: --------------------------------- Summary: Undeploy doesn't remove Data content if server is in --admin-only mode Key: WFCORE-1392 URL: https://issues.jboss.org/browse/WFCORE-1392 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 2.1.0.CR2 Reporter: Chao Wang Assignee: Jason Greene {noformat} Steps to Reproduce: 1. Start server instance using --admin-only flag 2. Deploy application using CLI command. ~~~ deploy /valid/path/WebApp.war --runtime-name=WebApp.war --name=WebApp.war ~~~ 3. Undeploy application using CLI command: ~~~ undeploy WebApp.war ~~~ 4. Application will be undeployed but content from 'data' directory are not removed. {noformat} Lines: https://github.com/wildfly/wildfly-core/blob/b1a4439f442f7984e681840c0f8d... https://github.com/wildfly/wildfly-core/blob/e737eff554ee433ca54835154fd6... runningMode value is ADMIN_ONLY will bypass that step in DeploymentRemoveHandler.java leads to this behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

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

by John Ament (JIRA)

[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ] John Ament commented on WFLY-2387: ---------------------------------- Its a little odd, shouldn't hibernate just look up the entity listener when needed at runtime, instead of eagerly loading it? I don't recall the spec requiring things like entity listener being app scoped, which this seems to assume. > 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 > 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.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-6127. ------------------------------ Resolution: Done > Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6127 > URL: https://issues.jboss.org/browse/WFLY-6127 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 9.0.2.Final > Reporter: Mazen Mahmoud > Assignee: Scott Marlow > Priority: Blocker > Fix For: 10.1.0.Final > > Attachments: server-log.txt > > > SPEC: If a component is called and the JTA transaction is propagated into that component: > If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED > associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container > We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED) > stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED) > SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED): > PC is propagated from SFB1 to SFB2 without any exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3805) JGroupsBroadcastGroupConfiguration Serialization Problem

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-3805?page=com.atlassian.jira.plugin.... ] Yong Hao Gao closed WFLY-3805. ------------------------------ Release Notes Text: Fixed into Artemis. Resolution: Rejected > JGroupsBroadcastGroupConfiguration Serialization Problem > -------------------------------------------------------- > > Key: WFLY-3805 > URL: https://issues.jboss.org/browse/WFLY-3805 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 10.1.0.Final > > > When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2948) Welcome file does not work for *.jsf

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2948?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2948: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1256325|https://bugzilla.redhat.com/show_bug.cgi?id=1256325] from ASSIGNED to MODIFIED > Welcome file does not work for *.jsf > -------------------------------------- > > Key: WFLY-2948 > URL: https://issues.jboss.org/browse/WFLY-2948 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Gulam Samdani > Assignee: Remy Maucherat > Priority: Minor > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Welcome file does not work for *.jsf > -------------------------------------------------------- > same problem not exists in Wildfly Beta but wildfly 8 final /cr1 gives this error ... > > problem : > > http://localhost:8080/hello ------------------------------ NO works*** > @http://localhost:8080/hello/index.jsf ------------- it works fine > ======================================= > <welcome-file-list> > > <welcome-file>index.jsf</welcome-file> > > </welcome-file-list> > <servlet> > <servlet-name>Faces Servlet</servlet-name> > <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > <servlet-mapping> > <servlet-name>Faces Servlet</servlet-name> > <url-pattern>*.jsf</url-pattern> > </servlet-mapping> > </web-app> > ------------------------------------------------- > Reproduce this error : > https://community.jboss.org/message/857300 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5242?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5242: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1260566|https://bugzilla.redhat.com/show_bug.cgi?id=1260566] from POST to MODIFIED > Inconsistent format for IPv6 addresses in server log > ---------------------------------------------------- > > Key: WFLY-5242 > URL: https://issues.jboss.org/browse/WFLY-5242 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Beta2 > Reporter: Lyle Wang > Assignee: Chao Wang > Priority: Minor > Fix For: 10.0.0.CR1 > > > Description of problem: > When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs. > How reproducible: > Always > Steps to Reproduce: > 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports) > 2. Start WildFly and check the log > Actual results: > ---------------------------------------- > 2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080 > ...... > 2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management > 2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993 > ---------------------------------------- > In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management" > Expected results: > Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1370) All configuration changes have the same operation date

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1370?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1370: ------------------------------------- Fix Version/s: 3.0.0.Alpha1 > All configuration changes have the same operation date > ------------------------------------------------------ > > Key: WFCORE-1370 > URL: https://issues.jboss.org/browse/WFCORE-1370 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha1 > > > When I list the changes, the operation date for all of the changes are the same, and seem to be the date/time when the `list-changes` operation is performed. I tried this just now with ER5: -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6235) Undertow mod_cluster should use multicast port from socket binding

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6235: ------------------------------------ Summary: Undertow mod_cluster should use multicast port from socket binding Key: WFLY-6235 URL: https://issues.jboss.org/browse/WFLY-6235 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Currently uses org.jboss.as.network.SocketBinding#getPort -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 February 2016