Problem with the new config.xml and deployer.jar

[David Jencks <da...@yahoo.com>]

There seems to be a problem with the new config.xml and running 
deployer.jar.  If you override something in RuntimeDeployer and then 
run deployer.jar, your new section for RuntimeDeployer is removed.

I'm not sure what a reasonable solution for this is.  Any ideas?

thanks
david jencks

Re: Problem with the new config.xml and deployer.jar

[David Jencks <da...@yahoo.com>]

DOH! user error.  I forgot the overwrite="true" flag in ant:copy

sorry for the false alarm

david jencks

On Aug 29, 2005, at 12:02 PM, David Jencks wrote:

> I'll investigate some more also.  It is possible I'm making a mistake 
> somewhere
>
> david jencks
>
> On Aug 29, 2005, at 12:17 PM, Aaron Mulder wrote:
>
>> On Mon, 29 Aug 2005, David Jencks wrote:
>>> I haven't investigated to the extent of writing a unit test, but I
>>> think I have observed repeatedly that after geronimo shuts down,
>>> config.xml only has sections for configurations that were actually
>>> started.  I think this might not be the behavior we want.
>>
>> 	That's certainly not the behavior we want.  But I can't reproduce
>> what you describe.  I just added a bogus configuration to my 
>> config.xml,
>> started and stopped Geronimo, and the file had not been overwritten 
>> at all
>> (bogus entry was still there, as well as comments that are always 
>> stripped
>> on rewrite).
>>
>> 	I then started it, went into the console, saved a web connector,
>> and shut down.  The file was overwritten (and comments stripped), but 
>> my
>> bogus section was still there.  If things are being removed, there 
>> has to
>> be some more complex cause.  I'll poke around a little.
>>
>> Aaron
>>
>

Re: Problem with the new config.xml and deployer.jar

[David Jencks <da...@yahoo.com>]

I'll investigate some more also.  It is possible I'm making a mistake 
somewhere

david jencks

On Aug 29, 2005, at 12:17 PM, Aaron Mulder wrote:

> On Mon, 29 Aug 2005, David Jencks wrote:
>> I haven't investigated to the extent of writing a unit test, but I
>> think I have observed repeatedly that after geronimo shuts down,
>> config.xml only has sections for configurations that were actually
>> started.  I think this might not be the behavior we want.
>
> 	That's certainly not the behavior we want.  But I can't reproduce
> what you describe.  I just added a bogus configuration to my 
> config.xml,
> started and stopped Geronimo, and the file had not been overwritten at 
> all
> (bogus entry was still there, as well as comments that are always 
> stripped
> on rewrite).
>
> 	I then started it, went into the console, saved a web connector,
> and shut down.  The file was overwritten (and comments stripped), but 
> my
> bogus section was still there.  If things are being removed, there has 
> to
> be some more complex cause.  I'll poke around a little.
>
> Aaron
>

Re: Problem with the new config.xml and deployer.jar

[Aaron Mulder <am...@alumni.princeton.edu>]

On Mon, 29 Aug 2005, David Jencks wrote:
> I haven't investigated to the extent of writing a unit test, but I 
> think I have observed repeatedly that after geronimo shuts down, 
> config.xml only has sections for configurations that were actually 
> started.  I think this might not be the behavior we want.

	That's certainly not the behavior we want.  But I can't reproduce
what you describe.  I just added a bogus configuration to my config.xml,
started and stopped Geronimo, and the file had not been overwritten at all
(bogus entry was still there, as well as comments that are always stripped
on rewrite).

	I then started it, went into the console, saved a web connector, 
and shut down.  The file was overwritten (and comments stripped), but my 
bogus section was still there.  If things are being removed, there has to 
be some more complex cause.  I'll poke around a little.

Aaron

Re: Problem with the new config.xml and deployer.jar

[David Jencks <da...@yahoo.com>]

On Aug 29, 2005, at 11:58 AM, Aaron Mulder wrote:

> On Mon, 29 Aug 2005, David Jencks wrote:
>> There seems to be a problem with the new config.xml and running
>> deployer.jar.  If you override something in RuntimeDeployer and then
>> run deployer.jar, your new section for RuntimeDeployer is removed.
>
> 	That curious -- it's not supposed to remove anything.  Generally,
> it loads everything in the file into a Map, and then during shutdown,
> writes the Map back out again.

I haven't investigated to the extent of writing a unit test, but I 
think I have observed repeatedly that after geronimo shuts down, 
config.xml only has sections for configurations that were actually 
started.  I think this might not be the behavior we want.

david jencks

>
> 	I think I did put a copy of the attribute store GBean into the
> deployer configuration, because otherwise the Configuration (or 
> somethign
> in that configuration, at any rate) was unhappy.  But that was 
> probably a
> mistake if that means the deployer will actually try to use (and
> overwrite) the same file that the server is using.
>
> 	Sounds like maybe we should remove the attribute store from the
> deployer-system configuration and just make sure that doesn't cause any
> problems.  Or perhaps better, make that one "read only".  It seems more
> likely to be the problem than the server's Map "losing" information.
>
> Aaron
>

Re: Problem with the new config.xml and deployer.jar

[Aaron Mulder <am...@alumni.princeton.edu>]

On Mon, 29 Aug 2005, David Jencks wrote:
> There seems to be a problem with the new config.xml and running 
> deployer.jar.  If you override something in RuntimeDeployer and then 
> run deployer.jar, your new section for RuntimeDeployer is removed.

	That curious -- it's not supposed to remove anything.  Generally, 
it loads everything in the file into a Map, and then during shutdown, 
writes the Map back out again.

	I think I did put a copy of the attribute store GBean into the
deployer configuration, because otherwise the Configuration (or somethign
in that configuration, at any rate) was unhappy.  But that was probably a
mistake if that means the deployer will actually try to use (and
overwrite) the same file that the server is using.

	Sounds like maybe we should remove the attribute store from the
deployer-system configuration and just make sure that doesn't cause any
problems.  Or perhaps better, make that one "read only".  It seems more
likely to be the problem than the server's Map "losing" information.

Aaron