On Wed, 26 Sep 2001 17:49, Ulrich Mayring wrote:
> Peter Donald wrote:
> > Hmmm then there is something wrong here. I just went and updated 9
> > projects that use phoenix and I managed to bring them up to speed in
> > about 35 minutes.
>
> Perhaps because you wrote the stuff and I'm just a user without docs? :)
probably. I will try to be more clear about things that will need changing in
future then ;)
> > Even then all the changes of late in Phoenix have been backwards
> > compatible and only issue warnings when you dont comply.
>
> Well, recently I had to convert all my blocks to interfaces.
Not sure what you mean.
> Then the
> ThreadManager section left server.xml, went to config.xml and became its
> own block. I had to figure out which of the cornerstone blocks use it.
> Then I had to add <block> sections instead of <meta> sections etc.
>
> It really doesn't help much to deprecate and keep backwards
> compatibility, because that only delays the point where things break. So
> I better fix it now, because in several months I won't know anymore what
> I have to do.
Well my hope was that displaying warning messages explaining what was wrong
would make it easier to migrate to new interfaces. Some of the messages were
less specific but I have just made them more a bit more useful today and so
you should get exact messages telling you what to change.
Anyways this is probably just an active period. I have had two weeks off and
needed to keep active ;) So the slew of changes is definetly not a regular
occurence.
> > The changes that I am suggesting are almost required as the basis of
> > further progress. For instance a requested features is that .sar files
> > are not extracted onto filesystem if at all possible to stop people
> > accidently messing up the deployments. This is not really possible to do
> > now because we don't know which parts are safe to be kept in archive and
> > which need to be extracted. It is also required if/when I get around to
> > adding in some funky deployment management stuff.
>
> Well, this sounds nice, but I'd prefer if the current mechanism would
> work first. The .sar archives are not reliably expanded, sometimes old
> files from previous .sar archives are not overwritten. Perhaps have
> Avalon automatically delete the deployment directory on startup? That's
> what I currently have to do.
The problem is that the current mechanism is expected behaviour. If the
directory has already been extracted then it won't be written over. This was
to follow trends with other similar systems (specifically Tomcat3.x and many
other servlet containers).
It wouldn't be possible to delete this directory because many applications
use this directory to store extra information generated at runtime. For
instance it could be used to store a mail spool, log files, or virtually
anything else that the server generates/uses.
> > Anyways what I would suggest is that you complain loudly about specific
> > changes if you don't like them ;) That way we can add more backwards
> > compatability/transitioning support or maybe revert the change.
>
> My suggestion is to change things when it becomes necessary, not before.
> So, once you start to actually do some funky stuff with .sar archives,
> that would be a good time to change the .sar structure, if required.
> It's easier to sell to the users, because they immediately see what they
> get for it :)
Well I would suggest that you stay with recently released phoenix for a while
and perhaps wait till beta before grabbing next download.
I don't have the time/resources to develope in large steps. It has to be
incremental changes when I or other peeps have time. If we were to require
these large steps nothing would ever get done ;)
--
Cheers,
Pete
--------------------------------------------------
Where ignorance is bliss, 'tis folly to be wise.
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
