August 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8517) Add support for two phase bundle deployments

by Thomas Diesler (JIRA)

Add support for two phase bundle deployments -------------------------------------------- Key: JBAS-8517 URL: https://jira.jboss.org/browse/JBAS-8517 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: OSGi integration Reporter: Thomas Diesler Fix For: 7.0.0.M1 In one deploy cycle, bundles must first get installed and then started. It generally needs to be discussed how multiple phase deployments should be handled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

5
24
0 / 0

[JBoss JIRA] (AS7-5379) CLONE - Stale data received with SYNC on failover

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/AS7-5379?page=com.atlassian.jira.plugin.s... ] Paul Ferraro commented on AS7-5379: ----------------------------------- Nevermind - I found the problem. > CLONE - Stale data received with SYNC on failover > ------------------------------------------------- > > Key: AS7-5379 > URL: https://issues.jboss.org/browse/AS7-5379 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Environment: affected 6.0.0 DR CI build > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Priority: Blocker > Labels: as713tracking > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > > After verifying fix for JBPAPP-8937 I am instead seeing stale data received when using DIST SYNC replication. > REPL SYNC: On a failover after the application has been gracefully undeployed, a request can be getting data older by cca 40 seconds: > {noformat} > 2012/08/14 15:12:53:327 EDT [WARN ][Runner - 1295] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295> > org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295 > at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125) > at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51) > at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87) > at java.lang.Thread.run(Thread.java:662) > {noformat} > DIST SYNC: On server crash stale data can be received: > {noformat} > 2012/08/04 05:13:49:714 EDT [WARN ][Runner - 8] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8> > org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8 > at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125) > at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51) > at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87) > at java.lang.Thread.run(Thread.java:662) > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-5379) CLONE - Stale data received with SYNC on failover

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5379?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-5379: --------------------------------------- How will you know? > CLONE - Stale data received with SYNC on failover > ------------------------------------------------- > > Key: AS7-5379 > URL: https://issues.jboss.org/browse/AS7-5379 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Environment: affected 6.0.0 DR CI build > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Priority: Blocker > Labels: as713tracking > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > > After verifying fix for JBPAPP-8937 I am instead seeing stale data received when using DIST SYNC replication. > REPL SYNC: On a failover after the application has been gracefully undeployed, a request can be getting data older by cca 40 seconds: > {noformat} > 2012/08/14 15:12:53:327 EDT [WARN ][Runner - 1295] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295> > org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295 > at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125) > at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51) > at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87) > at java.lang.Thread.run(Thread.java:662) > {noformat} > DIST SYNC: On server crash stale data can be received: > {noformat} > 2012/08/04 05:13:49:714 EDT [WARN ][Runner - 8] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8> > org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8 > at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125) > at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51) > at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87) > at java.lang.Thread.run(Thread.java:662) > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-5383) Update JSF based on Mojarra 2.1.12 and include patch for AS7-5373

by Stan Silvert (JIRA)

Stan Silvert created AS7-5383: --------------------------------- Summary: Update JSF based on Mojarra 2.1.12 and include patch for AS7-5373 Key: AS7-5383 URL: https://issues.jboss.org/browse/AS7-5383 Project: Application Server 7 Issue Type: Feature Request Components: JSF Affects Versions: 7.2.0.Alpha1 Reporter: Stan Silvert Assignee: Stan Silvert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
2
0 / 0

[JBoss JIRA] (AS7-5384) Apply AS7-5373 fix to master

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5384: ------------------------------------- Summary: Apply AS7-5373 fix to master Key: AS7-5384 URL: https://issues.jboss.org/browse/AS7-5384 Project: Application Server 7 Issue Type: Sub-task Components: JSF Reporter: Brian Stansberry Assignee: Stan Silvert Fix For: 7.2.0.Alpha1 Just recording the task to get the parent issue fixed in master. See Stan's last comment re: his plan for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
1
0 / 0

[JBoss JIRA] (JBRULES-3330) Provide MoveFilter for generic factories

by Lukáš Petrovický (Created) (JIRA)

Provide MoveFilter for generic factories ---------------------------------------- Key: JBRULES-3330 URL: https://issues.jboss.org/browse/JBRULES-3330 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Affects Versions: 5.4.0.Beta1 Reporter: Lukáš Petrovický Assignee: Mark Proctor At the moment, generic factories are far too generic - for most of the problems, an optimization can be found so that the amount of reasonable moves is significantly reduced. The intention is to allow customization of the generic move factories, while still using all their power. Generic move factory simply produces every possible move and the user defines, in a MoveFilter, which of them shouldn't be passed to the planner. The feature could work like this: 1. An interface is introduced, called eg. MoveFilter<T extends Move>. This interface declares one method - boolean filter(Solution solution, T move). This method accepts the solution of the MoveFactory, as well as the Move object that's been created by the MoveFactory. It returns true if the GenericMove should be included in the createMoveList() method of the MoveFactory, false otherwise. (Please make sure that the MoveFilter type is generic, so that filter() always knows the correct type of the move without the user doing any magic or assumptions. This would most probably require making MoveFactory generic as well, but that could be useful.) 2. Implementations of the MoveFilter interface are annotated with @MoveFilter(factory = [SomeMoveFactory.class, SomeOtherMoveFactory.class]). This annotation would specify to which move factory this filter should be related. Some checks should be put in place that the annotation will only work when the MoveFilter and MoveFactory share the same Move type. 3. The same as in (2) can be achieved by specifying filters in the XML configuration of the solver, altough I personally don't like the XML configs much. 4. MoveFactory's createMoveList() method is enhanced so that it runs user-specified MoveFilters and excludes the filtered moves from the resulting MoveList. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
4
0 / 0

[JBoss JIRA] (JBRULES-3605) TMS gets corrupted when traiting logically-inserted java (non @Traitable) POJOs

by Davide Sottara (JIRA)

Davide Sottara created JBRULES-3605: --------------------------------------- Summary: TMS gets corrupted when traiting logically-inserted java (non @Traitable) POJOs Key: JBRULES-3605 URL: https://issues.jboss.org/browse/JBRULES-3605 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.4.0.Final Reporter: Davide Sottara Assignee: Davide Sottara Fix For: 5.5.0.Beta1 Non @Traitable beans require wrapping to be traited. The OTN created for the wrapper does not share the TMS-enabled status with the OTN for the original class -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
1
0 / 0

[JBoss JIRA] (JBRULES-3556) Support mappings between trait and core class fields

by Davide Sottara (JIRA)

Davide Sottara created JBRULES-3556: --------------------------------------- Summary: Support mappings between trait and core class fields Key: JBRULES-3556 URL: https://issues.jboss.org/browse/JBRULES-3556 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-compiler, drools-core Affects Versions: 5.4.0.Final Reporter: Davide Sottara Assignee: Davide Sottara Priority: Minor Fix For: 5.5.0.Beta1 Trait - Core field mapping requires the fields to have the same name and compatible types. Whenever the names cannot be the same, e.g. due to interface naming requirements, it could be desirable to define a custom mapping: declare trait X tfield : String @Alias("cField") end declare Y cField : String end Here, tField should be mapped onto the hard field cField, even if the names are different -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
1
0 / 0

[JBoss JIRA] (AS7-3961) Provide "destroy-queue" and "destroy-topic" operations to CLI

by Miroslav Novak (JIRA)

Miroslav Novak created AS7-3961: ----------------------------------- Summary: Provide "destroy-queue" and "destroy-topic" operations to CLI Key: AS7-3961 URL: https://issues.jboss.org/browse/AS7-3961 Project: Application Server 7 Issue Type: Feature Request Components: CLI Affects Versions: 7.1.0.Final Reporter: Miroslav Novak Assignee: Alexey Loubyansky Fix For: 7.1.2.Final Operations "destroy-queue" and "destroy-topic" would destroy queue/topic with all its messages and subscriptions. They would be used under for example /subsystem=messaging/hornetq-server=default/jms-queue=testQueue or /subsystem=messaging/hornetq-server=default/jms-topic=testTopic. The goal is to provide a simple way how to get rid of those objects to administrators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-3200) Support for dynamic typing (aka "traits")

by Davide Sottara (JIRA)

Support for dynamic typing (aka "traits") ----------------------------------------- Key: JBRULES-3200 URL: https://issues.jboss.org/browse/JBRULES-3200 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-compiler, drools-core (expert) Reporter: Davide Sottara Assignee: Davide Sottara Fix For: 5.3.0.Final A trait is a (partially) implemented interface that can be attached (and removed) to an instance at runtime -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

5
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2012