You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2009/10/21 19:33:03 UTC
Re: ConfigurationUtil.getEditableConfigurationManager no longer needed?
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?
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 <xh...@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 <ri...@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
Re: ConfigurationUtil.getEditableConfigurationManager no longer needed?
Posted by Ivan <xh...@gmail.com>.
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 <ri...@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 <ma...@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
>>>> <ma...@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
>>>> <ma...@gmail.com>
>>>> <mailto:xhhsld@gmail.com
>>>>
>>>> <ma...@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
>>>> <ma...@gmail.com>
>>>> <mailto:rickmcg@gmail.com
>>>>
>>>> <ma...@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
Re: ConfigurationUtil.getEditableConfigurationManager no longer
needed?
Posted by Rick McGuire <ri...@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
>> <ma...@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 <ma...@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
>>> <ma...@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
>>> <ma...@gmail.com>
>>> <mailto:xhhsld@gmail.com
>>> <ma...@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
>>> <ma...@gmail.com>
>>> <mailto:rickmcg@gmail.com
>>> <ma...@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
>
Re: ConfigurationUtil.getEditableConfigurationManager no longer needed?
Posted by David Jencks <da...@yahoo.com>.
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 <da...@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 <xh...@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 <ri...@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 <ma...@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
>> <ma...@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
Re: ConfigurationUtil.getEditableConfigurationManager no longer
needed?
Posted by Ivan <xh...@gmail.com>.
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 ?
2009/10/23 David Jencks <da...@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 <xh...@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 <ri...@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 <ma...@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
>>>>> <ma...@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
Re: ConfigurationUtil.getEditableConfigurationManager no longer needed?
Posted by David Jencks <da...@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 <xh...@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 <ri...@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 <ma...@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
> <ma...@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
Re: ConfigurationUtil.getEditableConfigurationManager no longer
needed?
Posted by Ivan <xh...@gmail.com>.
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 <xh...@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 <ri...@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 <ma...@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
>>>> <ma...@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
Re: ConfigurationUtil.getEditableConfigurationManager no longer
needed?
Posted by Ivan <xh...@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 <ri...@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 <ma...@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
>>> <ma...@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
Re: ConfigurationUtil.getEditableConfigurationManager no longer
needed?
Posted by Rick McGuire <ri...@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 <ma...@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
>> <ma...@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
>