February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1394) default maxPermgen is added when jvm isn't configured

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1394?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1394: ------------------------------------------ I already assigned the JBEAP as I went to check its Target Release. > default maxPermgen is added when jvm isn't configured > ------------------------------------------------------ > > Key: WFCORE-1394 > URL: https://issues.jboss.org/browse/WFCORE-1394 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Martin Simka > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > Default maxPermgen size is added when {{jvm}} element isn't specified in domain.xml/host.xml and warning is logged. > {code:xml} > <server-group name="main-server-group" profile="default"> >  > <socket-binding-group ref="standard-sockets"/> > </server-group> > {code} > {noformat} > WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: null > {noformat} > It happens because default is defined in [JvmElement.java#L76|https://github.com/wildfly/wildfly-core/blob/master/h...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1394) default maxPermgen is added when jvm isn't configured

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1394?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1394: ------------------------------------- Fix Version/s: 3.0.0.Alpha1 > default maxPermgen is added when jvm isn't configured > ------------------------------------------------------ > > Key: WFCORE-1394 > URL: https://issues.jboss.org/browse/WFCORE-1394 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Martin Simka > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > Default maxPermgen size is added when {{jvm}} element isn't specified in domain.xml/host.xml and warning is logged. > {code:xml} > <server-group name="main-server-group" profile="default"> >  > <socket-binding-group ref="standard-sockets"/> > </server-group> > {code} > {noformat} > WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: null > {noformat} > It happens because default is defined in [JvmElement.java#L76|https://github.com/wildfly/wildfly-core/blob/master/h...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1394) default maxPermgen is added when jvm isn't configured

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1394?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1394: ---------------------------------------- Assignee: Ken Wills (was: Brian Stansberry) Ken, could you look into this one? Please assign yourself to the JBEAP as well. > default maxPermgen is added when jvm isn't configured > ------------------------------------------------------ > > Key: WFCORE-1394 > URL: https://issues.jboss.org/browse/WFCORE-1394 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Martin Simka > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > Default maxPermgen size is added when {{jvm}} element isn't specified in domain.xml/host.xml and warning is logged. > {code:xml} > <server-group name="main-server-group" profile="default"> >  > <socket-binding-group ref="standard-sockets"/> > </server-group> > {code} > {noformat} > WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: null > {noformat} > It happens because default is defined in [JvmElement.java#L76|https://github.com/wildfly/wildfly-core/blob/master/h...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6239) CLI: adding a JNDI entry with defualt value containing a '$' at the end

by Valentin Maechler (JIRA)

Valentin Maechler created WFLY-6239: --------------------------------------- Summary: CLI: adding a JNDI entry with defualt value containing a '$' at the end Key: WFLY-6239 URL: https://issues.jboss.org/browse/WFLY-6239 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 10.0.0.Final Reporter: Valentin Maechler Assignee: Alexey Loubyansky Can not add a JNDI / naming entry which contains a "$" sign at the end of it's default value. e.g. value="${my.sample.property1:entry5-default-value-with-special-char-at-the-end-$}" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1377) WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1377?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1377: ------------------------------------------ You're welcome. :) > WFLYCTL0201: Unknown attribute 'server-state' using HTTP management API > ----------------------------------------------------------------------- > > Key: WFCORE-1377 > URL: https://issues.jboss.org/browse/WFCORE-1377 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.1.0.CR1 > Reporter: Martin Choma > Assignee: Brian Stansberry > > Unable to get server-state using http management API > {noformat} > [mchoma@localhost bin]$ curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server" : "server-one" }]], "name" : "server-state","json.pretty":1}' -u admin:admin > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth" > Content-Length: 77 > Content-Type: text/html > Date: Tue, 16 Feb 2016 08:09:39 GMT > HTTP/1.1 500 Internal Server Error > Connection: keep-alive > Authentication-Info: nextnonce="sI2Bu4kJcGgNMTQ1NTYxMDE3OTU2MVc91LWa8HnWzIKZ5I8UIlo=",qop="auth",rspauth="8e575a86f8dae40426abd49bbc8f8b8a",cnonce="YmNiNmM4YjA0NmZlYjQ5MzAwMDAyNjIxMDAwODNhODE=",nc=00000001 > Content-Type: application/json; charset=utf-8 > Content-Length: 131 > Date: Tue, 16 Feb 2016 08:09:39 GMT > { > "outcome" : "failed", > "failure-description" : "WFLYCTL0201: Unknown attribute 'server-state'", > "rolled-back" : true > {noformat} > Running analogous CLI command works OK. > {noformat} > [domain@127.0.0.1:9999 /] /host=slave/server=main-three:read-attribute(name=server-state) > { > "outcome" => "success", > "result" => "running" > } > {noformat} > Can't get server status neither with > {noformat} > curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "address" : [[{ "host" : "master" },{ "server-config" : "server-one" }]], "name" : "status","json.pretty":1}' -u admin:admin > ... > "WFLYCTL0201: Unknown attribute 'status'" > {noformat} > Issue can be seen in EAP 6, as well. -- 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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1392?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1392: ------------------------------------- Component/s: Domain Management (was: Server) > 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: Enhancement > Components: Domain Management > Affects Versions: 2.1.0.CR2 > Reporter: Chao Wang > Assignee: Jason Greene > Priority: Minor > > {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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1392?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1392: ------------------------------------- Issue Type: Enhancement (was: Bug) > 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: Enhancement > 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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1392?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1392: ------------------------------------- Priority: Minor (was: Major) > 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: Enhancement > Components: Server > Affects Versions: 2.1.0.CR2 > Reporter: Chao Wang > Assignee: Jason Greene > Priority: Minor > > {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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1392?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1392: ------------------------------------------ [~soul2zimate] No, that check is necessary. The other classes have it too, but it's inside the call to DeploymentHandlerUtil.deploy(). I don't regard this as a bug; the background content repo cleaner task is meant to clean up the repo when edge cases like this occur. > 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: ---------------------------------- The impression that I have from looking through this ticket, as well as the relevant HHH tickets, is that the assumption is that an entity listener is booted on start up of the persistence unit. While this is probably true of a non-CDI managed one, I would expect the entity listener to be looked up when needed to perform an operation instead of eagerly being initialized. This is the part where I think scoping may have some kind of impact. Suppose I have @RequestScoped public class MyListener implements EntityListener { .. } I would expect that this listener is used whenever needed within a single HTTP request. I think (and I haven't tested this yet) that instead a more global listener is used, probably created during app start up. Maybe I'm making a wild assumption, that's why I'm bringing it up to see what you think. Granted, the JPA spec doesn't use the term contextual reference, so I'm not sure if I'm reading too much between the lines either. How does this relate to this ticket? Well, these are two points. Probably the third is that if I'm starting up an application, I have various scopes active during start up. I might be doing work with JPA before CDI is fully loaded. The only valid places to do stuff like this is in AfterDeploymentValidation, the PostConstruct methods on app scoped beans, and observers for initialized application scoped events. In all of those cases, CDI should be fully running and JPA could in theory wait until that point to get its references to an entity listener needed for those operations, assuming there are no cyclic dependencies. > 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

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