May 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1635) RELAY2: Allow for load balancing for received messages among the local cluster

by Erik Salter (JIRA)

[ https://issues.jboss.org/browse/JGRP-1635?page=com.atlassian.jira.plugin.... ] Erik Salter commented on JGRP-1635: ----------------------------------- Yes please. > RELAY2: Allow for load balancing for received messages among the local cluster > ------------------------------------------------------------------------------- > > Key: JGRP-1635 > URL: https://issues.jboss.org/browse/JGRP-1635 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.9 > Reporter: Erik Salter > Assignee: Bela Ban > Fix For: 3.4 > > > I've prototyped a configuration option that load-balances applying the changes from a remote SiteMaster across all local nodes in a cluster. > There is still a single SiteMaster (thereby not breaking the existing JGroups model); the difference is that the messages are now forwarded to other nodes in the local cluster and delivered to the application layer there for unmarshalling and processing. -- 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBAS-9542) Log file jboss.log gets truncated after restarting the server

by Sergey Goldberg (JIRA)

Sergey Goldberg created JBAS-9542: ------------------------------------- Summary: Log file jboss.log gets truncated after restarting the server Key: JBAS-9542 URL: https://issues.jboss.org/browse/JBAS-9542 Project: Application Server 3 4 5 and 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: 6.1.0 Environment: Windows, Linux Reporter: Sergey Goldberg Assignee: David Lloyd Every time the server is restarted its log file jboss.log gets truncated even when the "append" property is set to true (handler.FILE.append=true) in the logging.properties file. -- 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

12 years, 11 months

1
0
0 / 0

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

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-1429?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber updated WFLY-1429: -------------------------------------- Assignee: (was: Emanuel Muckenhuber) > 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

12 years, 11 months

1
0
0 / 0

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

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-1429?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber reassigned WFLY-1429: ----------------------------------------- Assignee: Emanuel Muckenhuber > 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 > Assignee: Emanuel Muckenhuber > > 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1186) Create JPA service callback for invoking database migration

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-1186?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-1186: ------------------------------------ [~anilarora], the JPA 2.1 specifications outline the new capabilities that will be in every JPA 2.1 persistence provider implementation (e.g. Hibernate 4.3.0). There is a JPA 2.1 way to generate scripts but also to specify the name of a DDL/DML SQL script to be executed. Exactly, how your/others needs are addressed by the JPA 2.1 specification, is open at this point. If you want to get involved with *scratching* your "database migration" itch, using the new JPA 2.1 specification features, that would be great. > Create JPA service callback for invoking database migration > ----------------------------------------------------------- > > Key: WFLY-1186 > URL: https://issues.jboss.org/browse/WFLY-1186 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Anil Arora > Assignee: Scott Marlow > > Looking for a simple callback/listener mechanism so that we can invoke a database migration script before JPA persistent unit starts up and runs the Hibernate schema validation mechanism. > Ideally, there would be a property within the persistence.xml that indicates which class to call. It would also pass in/inject the datasource that is being used for the persistence unit. > Essentially, this would solve the lack of migration support in Hibernate itself. -- 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

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1186) Create JPA service callback for invoking database migration

by Anil Arora (JIRA)

[ https://issues.jboss.org/browse/WFLY-1186?page=com.atlassian.jira.plugin.... ] Anil Arora commented on WFLY-1186: ---------------------------------- Not sure how the specs really help. The flyway migration framework takes in a DataSource object and executes a bunch of commands to do the migration. It doesn't return a list of SQL based scripts as some of the migrations use Java/JDBC directly to do some complicated migrations. > Create JPA service callback for invoking database migration > ----------------------------------------------------------- > > Key: WFLY-1186 > URL: https://issues.jboss.org/browse/WFLY-1186 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Anil Arora > Assignee: Scott Marlow > > Looking for a simple callback/listener mechanism so that we can invoke a database migration script before JPA persistent unit starts up and runs the Hibernate schema validation mechanism. > Ideally, there would be a property within the persistence.xml that indicates which class to call. It would also pass in/inject the datasource that is being used for the persistence unit. > Essentially, this would solve the lack of migration support in Hibernate itself. -- 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

12 years, 11 months

1
0
0 / 0

[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

12 years, 11 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

12 years, 11 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

12 years, 11 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

12 years, 11 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 May 2013