geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: ConfigurationUtil.getEditableConfigurationManager no longer needed?
Date Wed, 25 Aug 2010 01:36:56 GMT
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 <rickmcg@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_jencks@yahoo.com <mailto:
>>> david_jencks@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 <xhhsld@gmail.com <mailto:xhhsld@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 <rickmcg@gmail.com
>>>>        <mailto:rickmcg@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 <xhhsld@gmail.com
>>>>                    <mailto:xhhsld@gmail.com>
>>>>                    <mailto:xhhsld@gmail.com
>>>>
>>>>                    <mailto:xhhsld@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 <rickmcg@gmail.com
>>>>                    <mailto:rickmcg@gmail.com>
>>>>                    <mailto:rickmcg@gmail.com
>>>>
>>>>                    <mailto:rickmcg@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

Mime
View raw message