November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet resolved WFCORE-213. -------------------------------------- Fix Version/s: (was: 1.0.0.Beta1) Resolution: Done > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-211) HC is over eager to remove its content

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-211?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet updated WFCORE-211: ------------------------------------- Fix Version/s: 1.0.0.Alpha14 > HC is over eager to remove its content > -------------------------------------- > > Key: WFCORE-211 > URL: https://issues.jboss.org/browse/WFCORE-211 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha14 > > > If you deploy the same war twice (same hash with different names) on a domain then undeploy one the content is removed from the HC while it is still referenced and potentially useable. > The content is not removed from the servers content directory. > To reproduce : > deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=first.war --server-groups=main-server-group --name=first.war > deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=second.war --server-groups=main-server-group --name=second.war > undeploy first.war --all-relevant-server-groups -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-222) Update domain configuration files

by Emmanuel Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-222?page=com.atlassian.jira.plugin... ] Emmanuel Hugonnet updated WFCORE-222: ------------------------------------- Fix Version/s: 1.0.0.Alpha14 > Update domain configuration files > --------------------------------- > > Key: WFCORE-222 > URL: https://issues.jboss.org/browse/WFCORE-222 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha14 > > > After integration of WFCORE-75 the configuration files for the host haven't been updated to show this new option. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation

by Jay Kumar SenSharma (JIRA)

[ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.... ] Jay Kumar SenSharma reopened WFLY-1712: --------------------------------------- > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1712: ----------------------------------------------- Jay SenSharma <jsenshar(a)redhat.com> changed the Status of [bug 1017881|https://bugzilla.redhat.com/show_bug.cgi?id=1017881] from CLOSED to ASSIGNED > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-465) Attribute check-for-live-server must set on live server to faillback

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-465?page=com.atlassian.jira.plugin.s... ] Miroslav Novak closed WFLY-465. ------------------------------- Resolution: Done This is already resolved with EAP 6.3.0.ER7 - see bz#908261. Closing this jira. > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: WFLY-465 > URL: https://issues.jboss.org/browse/WFLY-465 > Project: WildFly > Issue Type: Task > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/inde... > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-451) Filter Apache CXF

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-451?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-451: ---------------------------------------------- Kyle Lape <klape(a)redhat.com> changed the Status of [bug 1166502|https://bugzilla.redhat.com/show_bug.cgi?id=1166502] from NEW to POST > Filter Apache CXF > ----------------- > > Key: WFLY-451 > URL: https://issues.jboss.org/browse/WFLY-451 > Project: WildFly > Issue Type: Task > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 8.0.0.Alpha1 > > > Detect Apache CXF libraries in user deployment and *if* the webservices subsystem is actually being triggered for the deployment, either log a major warning or make the deployment fail. This would basically prevent later issues with users trying to deploy not properly packaged applications (e.g. the same war embedding CXF they were using on Tomcat) and making them aware of what they need to do. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-451) Filter Apache CXF

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-451?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated WFLY-451: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1166502 > Filter Apache CXF > ----------------- > > Key: WFLY-451 > URL: https://issues.jboss.org/browse/WFLY-451 > Project: WildFly > Issue Type: Task > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 8.0.0.Alpha1 > > > Detect Apache CXF libraries in user deployment and *if* the webservices subsystem is actually being triggered for the deployment, either log a major warning or make the deployment fail. This would basically prevent later issues with users trying to deploy not properly packaged applications (e.g. the same war embedding CXF they were using on Tomcat) and making them aware of what they need to do. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-458) ServerInventory#reconnectServer should take auto-start into account

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-458?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-458: ------------------------------ Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFLY-458 > URL: https://issues.jboss.org/browse/WFLY-458 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Fix For: 9.0.0.Beta1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-368) Naming subsystem <lookup> could use LinkRef/Reference

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-368?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-368: ------------------------------ Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > Naming subsystem <lookup> could use LinkRef/Reference > ----------------------------------------------------- > > Key: WFLY-368 > URL: https://issues.jboss.org/browse/WFLY-368 > Project: WildFly > Issue Type: Feature Request > Components: Naming > Reporter: James Livingston > Assignee: Eduardo Martins > Fix For: 9.0.0.Beta1 > > > NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it. > It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead. > Where this could make a difference is when Context.lookupLink() is called instead. > Currently if you have > <simple name="java:/v" value="hello"/> > <lookup name="java:/a" lookup="java:/b"/> > lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b. > We need to decide whether a <lookup> should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

9 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2014