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 <[email protected]
<mailto:[email protected]>>
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 <[email protected] <mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>>
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 <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
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 <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
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
