The old codes should work, before we find a better way to replace it, or maybe when we finally turn to blueprint, I suggest to keep the EditableConfigurationManager and close the JIRA. Thanks.
2010/8/24 Rick McGuire <rick...@gmail.com> > I've been going through the open Jiras trying to figure out what the > dangling work items are left. This > > https://issues.apache.org/jira/browse/GERONIMO-4925 > > appears to be one that should have something done with it. What is the > state of the EditableConfigurationManager? There still appear to be some > dependencies on this in the code, but I'm not sure that code is actually > functional any more. I think if this is obsolete, then we should remove the > EditableCoinfigurationManager and fix the code that uses it to use its > logical replacement. If it is functional, then we can close this Jira out. > > Rick > > > On 10/23/2009 4:30 AM, David Jencks wrote: > >> >> On Oct 22, 2009, at 10:58 PM, Ivan wrote: >> >> Thanks, David, I opened a JIRA 4925 to track it. >>> I will temporarily enable it, so that we would not have any compile error >>> in the plugins. After the main integration work has been done, we could have >>> time to consider whether we still need it, or we have a better way to >>> implement it. >>> >>> About generating the bundle meta data in the deployment process, I am >>> interested that how it would be implemented in the deployer, use BND or ASM >>> tool ? >>> >> There is probably a better solution, but so far we've been ok with a >> simple calculation of the packages needed by the gbeans plus dynamic import >> package *. I wrote some code in ExecutableConfigurationUtil that collects >> the classes needed for the gbeans in the plan and saves the list of packages >> to a file, then the ArchiveCarMojo reads this and uses it to construct a >> manifest. Since IMO we should only be using packed plugins in 3.0 we should >> move all the archive functionality into the deployer somewhere, including >> figuring out the manifest needed. Very likely the archiveing code can just >> go into ExecutableConfigurationUtil. >> >> thanks >> david jencks >> >> >> >>> 2009/10/23 David Jencks <david_jen...@yahoo.com <mailto: >>> david_jen...@yahoo.com>> >>> >>> >>> To me, this issue of getting runtime modifications of running >>> plugins to persist or work at all is a very low priority item. I >>> think there is a very very good chance that once much of the >>> server is running we will step back look at what we have and >>> decide to completely change how this works, or if we allow it. I >>> think there are much more pressing issues such as the fact that >>> the osgi manifest info is put into plugins by the >>> car-maven-plugin rather than a deployer, so that the only way to >>> build a plugin or deploy an application is through a maven build >>> and assembling a custom server. So, I would comment out or >>> disable any functionality that requires >>> EditableConfigurationManager and file a jira so we don't forget >>> about it. >>> >>> However, as long as this doesn't constrain the basic architecture >>> in any way, I have no problem with anyone working on it. >>> >>> thanks >>> david jencks >>> >>> On Oct 22, 2009, at 7:50 AM, Ivan wrote: >>> >>> Hi, David: >>>> Do you have more comment on it ? Currently, I think that >>>> EditableConfigurationManager is a requried function, and I am >>>> sure that something is need to improve for it, Such as, it is >>>> better that we could have an attribute to mark it as "not >>>> started", because while we stop the connector in the console, >>>> after we restarting the server, the connector will start again IIRC. >>>> >>>> 2009/10/22 Ivan <xhh...@gmail.com <mailto:xhh...@gmail.com>> >>>> >>>> >>>> >>>> The ActiveMQ plugin also depends on it. >>>> Basically, since we allow the user to add new gbeans in the >>>> config.xml file for an existed configuration, we may need >>>> the API to do it programically. >>>> >>>> >>>> 2009/10/22 Rick McGuire <rick...@gmail.com >>>> <mailto:rick...@gmail.com>> >>>> >>>> >>>> David Jencks wrote: >>>> >>>> I would rather make the server work without this >>>> functionality. I'm really not sure its appropriate >>>> to modify plugins in this way. Can we catalog the >>>> places this functionality is absolutely required >>>> before we put it back in? >>>> >>>> Well, to start with, both the jetty and tomcat plugins >>>> are using it, and not just for running the tests. >>>> >>>> Rick >>>> >>>> >>>> thanks >>>> david jencks >>>> >>>> On Oct 21, 2009, at 6:06 AM, Ivan wrote: >>>> >>>> If no objection, I will try to recover those >>>> functions tomorrow, including the help methods >>>> in the ConfigurationUtil. >>>> >>>> 2009/10/21 Ivan <xhh...@gmail.com >>>> <mailto:xhh...@gmail.com> >>>> <mailto:xhh...@gmail.com >>>> >>>> <mailto:xhh...@gmail.com>>> >>>> >>>> >>>> Seems that EditableConfigurationManager >>>> support is removed (at >>>> least temporarily) in the Geronimo kernel. I >>>> am not sure that >>>> adding the gbeans to the existed >>>> configuration in the runtime is >>>> a good idea. But, IIRC, some plugins depend >>>> on it to add gbeans >>>> dynamically. >>>> I would suggest to recover it, the staff I >>>> could see is to change >>>> some codes to adapt the OSGI environment in >>>> its implemetation. >>>> >>>> 2009/10/21 Rick McGuire <rick...@gmail.com >>>> <mailto:rick...@gmail.com> >>>> <mailto:rick...@gmail.com >>>> >>>> <mailto:rick...@gmail.com>>> >>>> >>>> >>>> The Tomcat unit tests are making use of >>>> >>>> ConfigurationUtil.getEditableConfigurationManager, >>>> which has >>>> been commented out. Is that method no >>>> longer applicable, or >>>> does it still require some work? Is >>>> getConfigurationManager() an workable >>>> replacement? >>>> >>>> Rick >>>> >>>> >>>> >>>> >>>> -- Ivan >>>> >>>> >>>> >>>> >>>> -- Ivan >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- Ivan >>>> >>>> >>>> >>>> >>>> -- Ivan >>>> >>> >>> >>> >>> >>> -- >>> Ivan >>> >> >> > -- Ivan
