October 2013 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-246) Delete derived artifact are still available

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SRAMP-246?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated SRAMP-246: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1011937 > Delete derived artifact are still available > ------------------------------------------- > > Key: SRAMP-246 > URL: https://issues.jboss.org/browse/SRAMP-246 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Persistence > Reporter: Kurt Stam > Assignee: Kurt Stam > Fix For: 0.3.1 - jBPM - bugfix 1 > > > When a primary artifact is deleted the JCR node is moved from being rooted in '/s-ramp' to '/s-ramp-trash'. It's derived nodes are children and are moved as well. The JCR filter by '/s-ramp' still brings back the derived nodes, so they don't appear as being deleted. Opened a discussion with the ModeShape guys about this: https://community.jboss.org/message/840238#840238 -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-246) Delete derived artifact are still available

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SRAMP-246?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on SRAMP-246: ----------------------------------------------- Kurt T Stam <kurt.stam(a)redhat.com> changed the Status of [bug 1011937|https://bugzilla.redhat.com/show_bug.cgi?id=1011937] from NEW to ASSIGNED > Delete derived artifact are still available > ------------------------------------------- > > Key: SRAMP-246 > URL: https://issues.jboss.org/browse/SRAMP-246 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Persistence > Reporter: Kurt Stam > Assignee: Kurt Stam > Fix For: 0.3.1 - jBPM - bugfix 1 > > > When a primary artifact is deleted the JCR node is moved from being rooted in '/s-ramp' to '/s-ramp-trash'. It's derived nodes are children and are moved as well. The JCR filter by '/s-ramp' still brings back the derived nodes, so they don't appear as being deleted. Opened a discussion with the ModeShape guys about this: https://community.jboss.org/message/840238#840238 -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-246) Delete derived artifact are still available

by Kurt Stam (JIRA)

Kurt Stam created SRAMP-246: ------------------------------- Summary: Delete derived artifact are still available Key: SRAMP-246 URL: https://issues.jboss.org/browse/SRAMP-246 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Components: Persistence Reporter: Kurt Stam Assignee: Kurt Stam Fix For: 0.3.1 - jBPM - bugfix 1 When a primary artifact is deleted the JCR node is moved from being rooted in '/s-ramp' to '/s-ramp-trash'. It's derived nodes are children and are moved as well. The JCR filter by '/s-ramp' still brings back the derived nodes, so they don't appear as being deleted. Opened a discussion with the ModeShape guys about this: https://community.jboss.org/message/840238#840238 -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-289) Improve mechanism for obtainng core components where injection not possible

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-289?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-289: ---------------------------------- Issues: - need registration of epn, etc to be performed before server up, so blocking may be necessary unless another approach can be found - could use a shared state approach for the 'singleton' components, so multiple copies could be injected in different archives, rather than relying on a single singleton being created by the container and having to obtain a reference to it - however this approach means that EPN, ACS, IP (etc) archives would need to contain all of the relevant dependencies to resolve the beans - so for reducing dependencies/clutter/platform specific etc, it would be better if (for example) the EPN loader could obtain a reference to a previously initialized EventProcessorManager - current use of Singleton annotation has a problem, in that if BeanManager is used to obtain bean, then using the create method appears to create a new bean instance, regardless of the singleton annotation > Improve mechanism for obtainng core components where injection not possible > --------------------------------------------------------------------------- > > Key: RTGOV-289 > URL: https://issues.jboss.org/browse/RTGOV-289 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.M1 > > > Currently components within the overlord-rtgov.war can use CDI injection to resolve references. > However there are other places where the core components need to be accessed, that are outside this war, and therefore cannot benefit from CDI. > The current approach is to gets these components to register themselves with an 'accessor' class that manages a singleton reference. The problem is that due to startup initialisation order ambiguity, if the singleton has not been set, the caller must be blocked for a period of time. > Rather than block the deployer, it would be better to find an asynchronous approach to resolve these references. > Previously EJBs were being used to provide access to these components - and with the injection of those EJB resource, the dependencies were automatically managed by the container. However use of EJBs resulted in client proxies, which affected performance. > Need to rethink how these references are resolved in a way that is generally applicable. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-289) Improve mechanism for obtainng core components where injection not possible

by Gary Brown (JIRA)

Gary Brown created RTGOV-289: -------------------------------- Summary: Improve mechanism for obtainng core components where injection not possible Key: RTGOV-289 URL: https://issues.jboss.org/browse/RTGOV-289 Project: RTGov (Run Time Governance) Issue Type: Enhancement Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.M1 Currently components within the overlord-rtgov.war can use CDI injection to resolve references. However there are other places where the core components need to be accessed, that are outside this war, and therefore cannot benefit from CDI. The current approach is to gets these components to register themselves with an 'accessor' class that manages a singleton reference. The problem is that due to startup initialisation order ambiguity, if the singleton has not been set, the caller must be blocked for a period of time. Rather than block the deployer, it would be better to find an asynchronous approach to resolve these references. Previously EJBs were being used to provide access to these components - and with the injection of those EJB resource, the dependencies were automatically managed by the container. However use of EJBs resulted in client proxies, which affected performance. Need to rethink how these references are resolved in a way that is generally applicable. -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-288) Update quickstart readmes

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-288?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-288. ------------------------------ Resolution: Done > Update quickstart readmes > ------------------------- > > Key: RTGOV-288 > URL: https://issues.jboss.org/browse/RTGOV-288 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.M1 > > -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-288) Update quickstart readmes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/RTGOV-288?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated RTGOV-288: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1008659 > Update quickstart readmes > ------------------------- > > Key: RTGOV-288 > URL: https://issues.jboss.org/browse/RTGOV-288 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.M1 > > -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-288) Update quickstart readmes

by Gary Brown (JIRA)

Gary Brown created RTGOV-288: -------------------------------- Summary: Update quickstart readmes Key: RTGOV-288 URL: https://issues.jboss.org/browse/RTGOV-288 Project: RTGov (Run Time Governance) Issue Type: Enhancement Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.M1 -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-287) Accessor wait interval needs to be configurable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/RTGOV-287?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated RTGOV-287: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015363 > Accessor wait interval needs to be configurable > ----------------------------------------------- > > Key: RTGOV-287 > URL: https://issues.jboss.org/browse/RTGOV-287 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.M1 > > -- 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

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-287) Accessor wait interval needs to be configurable

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-287?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-287. ------------------------------ Resolution: Done > Accessor wait interval needs to be configurable > ----------------------------------------------- > > Key: RTGOV-287 > URL: https://issues.jboss.org/browse/RTGOV-287 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > -- 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

11 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues October 2013