May 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1429) Auto-promotion of slave HC to master based on a shared lock

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-1429: -------------------------------------- Summary: Auto-promotion of slave HC to master based on a shared lock Key: WFLY-1429 URL: https://issues.jboss.org/browse/WFLY-1429 Project: WildFly Issue Type: Feature Request Components: Domain Management Reporter: Brian Stansberry Implement an option for a properly configured slave HC to promote itself to master after acquiring an exclusive lock mediated via some persistent store shared between all HCs that are possibly master. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-188) CtClass detach does not completely clean class from pool.

by John Bainbridge (JIRA)

[ https://issues.jboss.org/browse/JASSIST-188?page=com.atlassian.jira.plugi... ] John Bainbridge commented on JASSIST-188: ----------------------------------------- When is this going to be released? > CtClass detach does not completely clean class from pool. > --------------------------------------------------------- > > Key: JASSIST-188 > URL: https://issues.jboss.org/browse/JASSIST-188 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.17.0-GA > Environment: Ubuntu, Windows, JDK 1.6/1.7 > Reporter: J D > Assignee: Shigeru Chiba > Priority: Critical > Fix For: 3.18.0-GA > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Description: > Class with same qualified name cannot be recreated even if previous class was detached successfully from pool. > Creation#1: Consider class eg.foo.MyClass is created using default pool and private int myArg1 private member along with some getter/setter methods. After its creation, the CtClass.detach is invoked successfully. > Creation#2: Subsequently, create eg.foo.MyClass using same default pool succeeds but any attempt to add members e.g. private int myArg1 fails with error: > Field myArg1 in eg.foo.MyClass is private. > Bug Analysis: > MemberCodeGen.isAccessibleField has f.getDeclaringClass from Creation#1 but thisClass is from Creation#2. This was traced to MemberResolver.invalidNamesMap. When Creation#1 detached the CtClass, it got removed from pool but not from the invalidNamesMap for default pool. Subsequently when MemberResolver.lookupClass looks for "eg.foo.MyClass", the Creation#1's CtClass gets returned. This is a bug because that class was detached earlier and must not be reused for any processing - we are creating another instance because a new definition is needed for that class. > The bug is critical as erroneous unintended cached class definitions could be used even when not intended leading to potentially very severe runtime problems. Remember that cache is a good only if it accurately provided cached results. In this case, stale/incorrect results will be returned. > Proposed Fix: > Add a static method detachInvalidNames in MemberResolver that removes a qualified class-name from invalidNamesMap for that class's pool. CtClass.detach must invoke this detachInvalidNames. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1428) Extra resource root added to WARs

by Remy Maucherat (JIRA)

[ https://issues.jboss.org/browse/WFLY-1428?page=com.atlassian.jira.plugin.... ] Remy Maucherat commented on WFLY-1428: -------------------------------------- +1 for not doing it at all by default at least. > Extra resource root added to WARs > --------------------------------- > > Key: WFLY-1428 > URL: https://issues.jboss.org/browse/WFLY-1428 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Reporter: David Lloyd > Assignee: Remy Maucherat > Fix For: 8.0.0.Alpha2 > > > When the class path for WAR deployments is being assembled, it appears that the WAR's root is being added as a resource root. This seems to be counter to spec; by default this should not be done. Now that we have the ability to iterate class loader resources, this causes unusual things to be listed. > Some users may desire this non-standard behavior though. So, we should have a way (preferably simpler than {{jboss-deployment-structure.xml}}) to enable it; however in this case, the following paths *must* be excluded: > * {{WEB-INF/lib}} > * {{WEB-INF/classes}} > * Any additional configured library or class directories > * Any other nested, mounted JAR files -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1428) Extra resource root added to WARs

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-1428?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-1428: ------------------------------ Description: When the class path for WAR deployments is being assembled, it appears that the WAR's root is being added as a resource root. This seems to be counter to spec; by default this should not be done. Now that we have the ability to iterate class loader resources, this causes unusual things to be listed. Some users may desire this non-standard behavior though. So, we should have a way (preferably simpler than {{jboss-deployment-structure.xml}}) to enable it; however in this case, the following paths *must* be excluded: * {{WEB-INF/lib}} * {{WEB-INF/classes}} * Any additional configured library or class directories * Any other nested, mounted JAR files was: When the class path for WAR deployments is being assembled, it appears that the WAR's root is being added as a resource root. This seems to be counter to spec; by default this should not be done. Now that we have the ability to iterate class loader resources, this causes unusual things to be listed. Some users may desire this non-standard behavior though. So, we should have a way (preferably simpler than {{jboss-deployment-structure.xml}}) to enable it; however in this case, the following paths *must* be excluded: * {{WEB-INF/lib}} * {{WEB-INF/classes}} * Any additional configured library or source directories * Any other nested, mounted JAR files > Extra resource root added to WARs > --------------------------------- > > Key: WFLY-1428 > URL: https://issues.jboss.org/browse/WFLY-1428 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Reporter: David Lloyd > Assignee: Remy Maucherat > Fix For: 8.0.0.Alpha2 > > > When the class path for WAR deployments is being assembled, it appears that the WAR's root is being added as a resource root. This seems to be counter to spec; by default this should not be done. Now that we have the ability to iterate class loader resources, this causes unusual things to be listed. > Some users may desire this non-standard behavior though. So, we should have a way (preferably simpler than {{jboss-deployment-structure.xml}}) to enable it; however in this case, the following paths *must* be excluded: > * {{WEB-INF/lib}} > * {{WEB-INF/classes}} > * Any additional configured library or class directories > * Any other nested, mounted JAR files -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1428) Extra resource root added to WARs

by David Lloyd (JIRA)

David Lloyd created WFLY-1428: --------------------------------- Summary: Extra resource root added to WARs Key: WFLY-1428 URL: https://issues.jboss.org/browse/WFLY-1428 Project: WildFly Issue Type: Bug Components: Web (JBoss Web), Web (Undertow) Reporter: David Lloyd Assignee: Remy Maucherat Fix For: 8.0.0.Alpha2 When the class path for WAR deployments is being assembled, it appears that the WAR's root is being added as a resource root. This seems to be counter to spec; by default this should not be done. Now that we have the ability to iterate class loader resources, this causes unusual things to be listed. Some users may desire this non-standard behavior though. So, we should have a way (preferably simpler than {{jboss-deployment-structure.xml}}) to enable it; however in this case, the following paths *must* be excluded: * {{WEB-INF/lib}} * {{WEB-INF/classes}} * Any additional configured library or source directories * Any other nested, mounted JAR files -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-405) Patching system

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-405?page=com.atlassian.jira.plugin.s... ] Emanuel Muckenhuber updated WFLY-405: ------------------------------------- Description: "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them. This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good. Links to the current wiki articles: https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... https://community.jboss.org/wiki/SingleInstallationPatching https://community.jboss.org/wiki/ExperimentingWithSingleInstallationPatching was: "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them. This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good. > Patching system > --------------- > > Key: WFLY-405 > URL: https://issues.jboss.org/browse/WFLY-405 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Priority: Blocker > Labels: rhq > Fix For: 8.0.0.Beta1 > > > "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them. > This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good. > Links to the current wiki articles: > https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... > https://community.jboss.org/wiki/SingleInstallationPatching > https://community.jboss.org/wiki/ExperimentingWithSingleInstallationPatching -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-4594) do not resolve socket-bindings used by messaging

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-4594?page=com.atlassian.jira.plugin.s... ] SBS JIRA Integration updated AS7-4594: -------------------------------------- Forum Reference: https://community.jboss.org/message/738099#738099 > do not resolve socket-bindings used by messaging > ------------------------------------------------ > > Key: AS7-4594 > URL: https://issues.jboss.org/browse/AS7-4594 > Project: Application Server 7 > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 7.1.2.Final (EAP) > > > HornetQ remote acceptors and connectors can be configured using socket-bindings. > The current code tries to resolve the socket address to get its host name that is serialized into JMS connection factories. > The client will then lookup a CF with the hostname to connect to AS7's HornetQ server. If the clients can not look up the host name, the connection will fail. > The messaging subsystem should not try to resolve the address but serialize it "as is" so that the client will use it directly. > The only exception is that *by default*, we use the loopback address for RemoteConnectionFactory. We need to check whether the socket address is a loopback and resolve it before serializing it for the client use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1638) Memory leak

by Bela Ban (JIRA)

Bela Ban created JGRP-1638: ------------------------------ Summary: Memory leak Key: JGRP-1638 URL: https://issues.jboss.org/browse/JGRP-1638 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Priority: Critical Fix For: 3.4 Running MPerf with conf/fast-local.xml (2 members on the same host, 20 million messages each) creates a memory leak in 3.4.x. This runs perfectly 3.2.8.Final, so it must be something that was introduced in 3.3.x (3.4.x at this time has almost no diffs to 3.3.0.Final). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-128) NoClassDefFoundError: org/apache/catalina/CometProcessor

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/JBWEB-128?page=com.atlassian.jira.plugin.... ] Jean-Frederic Clere resolved JBWEB-128. --------------------------------------- Resolution: Won't Fix CometProcessor is from the Tomcat implementation of Comet we don't support that in JBossWeb. > NoClassDefFoundError: org/apache/catalina/CometProcessor > -------------------------------------------------------- > > Key: JBWEB-128 > URL: https://issues.jboss.org/browse/JBWEB-128 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: JBossWeb-2.1.1.GA > Reporter: Mike Millson > Assignee: Jean-Frederic Clere > > Comet applications with dependencies on org.apache.catalina.CometProcessor will not run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1427) allow defining infinispan caches as part of *.ear deployment

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/WFLY-1427?page=com.atlassian.jira.plugin.... ] Tristan Tarrant moved ISPN-3155 to WFLY-1427: --------------------------------------------- Project: WildFly (was: Infinispan) Key: WFLY-1427 (was: ISPN-3155) Component/s: Clustering (was: Distributed Cache) > allow defining infinispan caches as part of *.ear deployment > ------------------------------------------------------------ > > Key: WFLY-1427 > URL: https://issues.jboss.org/browse/WFLY-1427 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Reporter: Radai Rosenblatt > Assignee: Mircea Markus > > right now (7.1.3) its possible to define datasources (either xml or annotation based) and jms destinations (xml) inside an *.ear deployment. > would be nice to be able to define caches, both local and clustered in a simlar (xml-based) way -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 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 May 2013