[jira] [Updated] (KARAF-3997) Subsystem feature does not save regions state after install of a subsystem causing a startup issue.
[ https://issues.apache.org/jira/browse/KARAF-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-3997: Fix Version/s: (was: 4.0.6) 4.0.7 > Subsystem feature does not save regions state after install of a subsystem > causing a startup issue. > --- > > Key: KARAF-3997 > URL: https://issues.apache.org/jira/browse/KARAF-3997 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.0.1 > Environment: java 1.7 >Reporter: Bas >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.0, 4.0.7 > > Attachments: application.esa, features-core.patch, > karaf-subsystem-restart-exception.txt > > > Problem: > Subsystem feature does not save digraph state after install of a subsystem > causing a startup issue showing the exception added as an attachment. > Reproduce: > Install karaf 4.0.1 > Install the subsystem feature > Install the attached application.esa file > Kill the osgi process (in an ungraceful way like kill -9) > Startup karaf > The above is a problem in the way features.core has encapsulated the region > bundle and changed the persistence (it is now saved in the file > 'digraph.json' which cannot be triggered by the class > 'StandardRegionDigraphPersistence'). When the region implementation was an > external bundle for karaf, it was possible to gain access to the persistence > logic by the use of and access to the class > 'StandardRegionDigraphPersistence' and save the file yourself if you changed > it. This is not possible anymore in karaf version 4.0.1. We would like to be > able to do so. > The feature.core functionality itself does save the state of the digraph on > install of a new feature but in a different file 'digraph.json'. > The subsystems feature and other features/bundles might want to persist the > digraph and get stability on ungraceful shutdowns in the same way as > installing a feature. > I made a patch where I am exporting an interface that can trigger > feature.core region persistence logic. It is a workaround for our code that > also uses the region functionality. So it is not that I'm advising to do it > like this. > Probably short term the patch could help, or a different solution like change > the persistence by making an own version of 'RegionDigraphPersistence'. This > class is exposed so others can use it (still there is trouble with the name > of the file and access to the bundle where the file is stored). > Long term, maybe move aries subsystem implementation to the core framework > and re-implement features support to use aries subsystems. > But also aries subsystems has trouble saving the digraph correctly, it is > depending on a higher level logic to take that responsibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-3997) Subsystem feature does not save regions state after install of a subsystem causing a startup issue.
[ https://issues.apache.org/jira/browse/KARAF-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-3997: Fix Version/s: 4.0.6 4.1.0 > Subsystem feature does not save regions state after install of a subsystem > causing a startup issue. > --- > > Key: KARAF-3997 > URL: https://issues.apache.org/jira/browse/KARAF-3997 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.0.1 > Environment: java 1.7 >Reporter: Bas >Assignee: Jean-Baptiste Onofré > Fix For: 4.1.0, 4.0.6 > > Attachments: application.esa, features-core.patch, > karaf-subsystem-restart-exception.txt > > > Problem: > Subsystem feature does not save digraph state after install of a subsystem > causing a startup issue showing the exception added as an attachment. > Reproduce: > Install karaf 4.0.1 > Install the subsystem feature > Install the attached application.esa file > Kill the osgi process (in an ungraceful way like kill -9) > Startup karaf > The above is a problem in the way features.core has encapsulated the region > bundle and changed the persistence (it is now saved in the file > 'digraph.json' which cannot be triggered by the class > 'StandardRegionDigraphPersistence'). When the region implementation was an > external bundle for karaf, it was possible to gain access to the persistence > logic by the use of and access to the class > 'StandardRegionDigraphPersistence' and save the file yourself if you changed > it. This is not possible anymore in karaf version 4.0.1. We would like to be > able to do so. > The feature.core functionality itself does save the state of the digraph on > install of a new feature but in a different file 'digraph.json'. > The subsystems feature and other features/bundles might want to persist the > digraph and get stability on ungraceful shutdowns in the same way as > installing a feature. > I made a patch where I am exporting an interface that can trigger > feature.core region persistence logic. It is a workaround for our code that > also uses the region functionality. So it is not that I'm advising to do it > like this. > Probably short term the patch could help, or a different solution like change > the persistence by making an own version of 'RegionDigraphPersistence'. This > class is exposed so others can use it (still there is trouble with the name > of the file and access to the bundle where the file is stored). > Long term, maybe move aries subsystem implementation to the core framework > and re-implement features support to use aries subsystems. > But also aries subsystems has trouble saving the digraph correctly, it is > depending on a higher level logic to take that responsibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-3997) Subsystem feature does not save regions state after install of a subsystem causing a startup issue.
[ https://issues.apache.org/jira/browse/KARAF-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré updated KARAF-3997: Fix Version/s: 4.0.2 > Subsystem feature does not save regions state after install of a subsystem > causing a startup issue. > --- > > Key: KARAF-3997 > URL: https://issues.apache.org/jira/browse/KARAF-3997 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.0.1 > Environment: java 1.7 >Reporter: Bas >Assignee: Jean-Baptiste Onofré > Fix For: 4.0.2 > > Attachments: application.esa, features-core.patch, > karaf-subsystem-restart-exception.txt > > > Problem: > Subsystem feature does not save digraph state after install of a subsystem > causing a startup issue showing the exception added as an attachment. > Reproduce: > Install karaf 4.0.1 > Install the subsystem feature > Install the attached application.esa file > Kill the osgi process (in an ungraceful way like kill -9) > Startup karaf > The above is a problem in the way features.core has encapsulated the region > bundle and changed the persistence (it is now saved in the file > 'digraph.json' which cannot be triggered by the class > 'StandardRegionDigraphPersistence'). When the region implementation was an > external bundle for karaf, it was possible to gain access to the persistence > logic by the use of and access to the class > 'StandardRegionDigraphPersistence' and save the file yourself if you changed > it. This is not possible anymore in karaf version 4.0.1. We would like to be > able to do so. > The feature.core functionality itself does save the state of the digraph on > install of a new feature but in a different file 'digraph.json'. > The subsystems feature and other features/bundles might want to persist the > digraph and get stability on ungraceful shutdowns in the same way as > installing a feature. > I made a patch where I am exporting an interface that can trigger > feature.core region persistence logic. It is a workaround for our code that > also uses the region functionality. So it is not that I'm advising to do it > like this. > Probably short term the patch could help, or a different solution like change > the persistence by making an own version of 'RegionDigraphPersistence'. This > class is exposed so others can use it (still there is trouble with the name > of the file and access to the bundle where the file is stored). > Long term, maybe move aries subsystem implementation to the core framework > and re-implement features support to use aries subsystems. > But also aries subsystems has trouble saving the digraph correctly, it is > depending on a higher level logic to take that responsibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-3997) Subsystem feature does not save regions state after install of a subsystem causing a startup issue.
[ https://issues.apache.org/jira/browse/KARAF-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bas updated KARAF-3997: --- Attachment: karaf-subsystem-restart-exception.txt The exception > Subsystem feature does not save regions state after install of a subsystem > causing a startup issue. > --- > > Key: KARAF-3997 > URL: https://issues.apache.org/jira/browse/KARAF-3997 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.0.1 > Environment: java 1.7 >Reporter: Bas > Attachments: application.esa, karaf-subsystem-restart-exception.txt > > > Problem: > Subsystem feature does not save digraph state after install of a subsystem > causing a startup issue showing the exception added as an attachment. > Reproduce: > Install karaf 4.0.1 > Install the subsystem feature > Install the attached application.esa file > Kill the osgi process (in an ungraceful way like kill -9) > Startup karaf > The above is a problem in the way features.core has encapsulated the region > bundle and changed the persistence (it is now saved in the file > 'digraph.json' which cannot be triggered by the class > 'StandardRegionDigraphPersistence'). When the region implementation was an > external bundle for karaf, it was possible to gain access to the persistence > logic by the use of and access to the class > 'StandardRegionDigraphPersistence' and save the file yourself if you changed > it. This is not possible anymore in karaf version 4.0.1. We would like to be > able to do so. > The feature.core functionality itself does save the state of the digraph on > install of a new feature but in a different file 'digraph.json'. > The subsystems feature and other features/bundles might want to persist the > digraph and get stability on ungraceful shutdowns in the same way as > installing a feature. > I made a patch where I am exporting an interface that can trigger > feature.core region persistence logic. It is a workaround for our code that > also uses the region functionality. So it is not that I'm advising to do it > like this. > Probably short term the patch could help, or a different solution like change > the persistence by making an own version of 'RegionDigraphPersistence'. This > class is exposed so others can use it (still there is trouble with the name > of the file and access to the bundle where the file is stored). > Long term, maybe move aries subsystem implementation to the core framework > and re-implement features support to use aries subsystems. > But also aries subsystems has trouble saving the digraph correctly, it is > depending on a higher level logic to take that responsibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-3997) Subsystem feature does not save regions state after install of a subsystem causing a startup issue.
[ https://issues.apache.org/jira/browse/KARAF-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bas updated KARAF-3997: --- Attachment: features-core.patch Patch that adds a persistence osgi service to the features core enabling other bundles to persist the digraph again. > Subsystem feature does not save regions state after install of a subsystem > causing a startup issue. > --- > > Key: KARAF-3997 > URL: https://issues.apache.org/jira/browse/KARAF-3997 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.0.1 > Environment: java 1.7 >Reporter: Bas > Attachments: application.esa, features-core.patch, > karaf-subsystem-restart-exception.txt > > > Problem: > Subsystem feature does not save digraph state after install of a subsystem > causing a startup issue showing the exception added as an attachment. > Reproduce: > Install karaf 4.0.1 > Install the subsystem feature > Install the attached application.esa file > Kill the osgi process (in an ungraceful way like kill -9) > Startup karaf > The above is a problem in the way features.core has encapsulated the region > bundle and changed the persistence (it is now saved in the file > 'digraph.json' which cannot be triggered by the class > 'StandardRegionDigraphPersistence'). When the region implementation was an > external bundle for karaf, it was possible to gain access to the persistence > logic by the use of and access to the class > 'StandardRegionDigraphPersistence' and save the file yourself if you changed > it. This is not possible anymore in karaf version 4.0.1. We would like to be > able to do so. > The feature.core functionality itself does save the state of the digraph on > install of a new feature but in a different file 'digraph.json'. > The subsystems feature and other features/bundles might want to persist the > digraph and get stability on ungraceful shutdowns in the same way as > installing a feature. > I made a patch where I am exporting an interface that can trigger > feature.core region persistence logic. It is a workaround for our code that > also uses the region functionality. So it is not that I'm advising to do it > like this. > Probably short term the patch could help, or a different solution like change > the persistence by making an own version of 'RegionDigraphPersistence'. This > class is exposed so others can use it (still there is trouble with the name > of the file and access to the bundle where the file is stored). > Long term, maybe move aries subsystem implementation to the core framework > and re-implement features support to use aries subsystems. > But also aries subsystems has trouble saving the digraph correctly, it is > depending on a higher level logic to take that responsibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-3997) Subsystem feature does not save regions state after install of a subsystem causing a startup issue.
[ https://issues.apache.org/jira/browse/KARAF-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bas updated KARAF-3997: --- Attachment: application.esa The subsystem application used > Subsystem feature does not save regions state after install of a subsystem > causing a startup issue. > --- > > Key: KARAF-3997 > URL: https://issues.apache.org/jira/browse/KARAF-3997 > Project: Karaf > Issue Type: Bug > Components: karaf-feature >Affects Versions: 4.0.1 > Environment: java 1.7 >Reporter: Bas > Attachments: application.esa > > > Problem: > Subsystem feature does not save digraph state after install of a subsystem > causing a startup issue showing the exception added as an attachment. > Reproduce: > Install karaf 4.0.1 > Install the subsystem feature > Install the attached application.esa file > Kill the osgi process (in an ungraceful way like kill -9) > Startup karaf > The above is a problem in the way features.core has encapsulated the region > bundle and changed the persistence (it is now saved in the file > 'digraph.json' which cannot be triggered by the class > 'StandardRegionDigraphPersistence'). When the region implementation was an > external bundle for karaf, it was possible to gain access to the persistence > logic by the use of and access to the class > 'StandardRegionDigraphPersistence' and save the file yourself if you changed > it. This is not possible anymore in karaf version 4.0.1. We would like to be > able to do so. > The feature.core functionality itself does save the state of the digraph on > install of a new feature but in a different file 'digraph.json'. > The subsystems feature and other features/bundles might want to persist the > digraph and get stability on ungraceful shutdowns in the same way as > installing a feature. > I made a patch where I am exporting an interface that can trigger > feature.core region persistence logic. It is a workaround for our code that > also uses the region functionality. So it is not that I'm advising to do it > like this. > Probably short term the patch could help, or a different solution like change > the persistence by making an own version of 'RegionDigraphPersistence'. This > class is exposed so others can use it (still there is trouble with the name > of the file and access to the bundle where the file is stored). > Long term, maybe move aries subsystem implementation to the core framework > and re-implement features support to use aries subsystems. > But also aries subsystems has trouble saving the digraph correctly, it is > depending on a higher level logic to take that responsibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
