startup test with custom 1.2 config
- config has
been put into repository/conf/synapse-config as it seems to got ignored in
I think this is by
design and we need to document this on the Upgrading guide.
- Synapse does
not startup due to a problem in the config (e.g. missing registry
implementation class on the classpath)
I will have a look
at this, I guess this needs to be fixed if there is an issue, can you please
give me a small config bit to re-produce this issue? may be you are using a
WSO2 ESB registry class shipped with WSO2 which of course is not available in
Yes, my aim was to test a failure case. So it was
absolutely expected that this fails. No issue at all!
behaviour: Although Synapse detects the problems, tries to perform a clean
shutdown, it “keeps hanging” and does not return to the shell with an error
Can you please
attach the log for this and steps to re-produce, this again I would like to fix
depending on the complexity of the issue... and if this gets slipped from 2.0.0
I suggest immediately spinning a 2.0.1 to fix this and any other this sort of issues
from the 2.0.0 branch. WDYT?
Yes, I personally do not consider this
critical – it is simply only not nice. By the way, the same condition can be
reached with many different issues in a user’s config. Reproduction is easy.
Just specify any class name non existing in the classpath e.g. as the registry
the migration tool expects a config in repository/conf (former config location)
If you type help
for the migration tool sh you will find that it is the default location the
script looks for but you can specify your own location too.
Maybe it would be slightly better if an no arg
execution outputs a usage instead of assuming the default location and
immediately starting to do something. But this is obviously a matter of taste…
- old copy
copied there and restarted
tool modifies config
- after migration config stays in repository/conf and needs
to be manually copied to repository/conf/synapse-conf to be recognized
This again is the
default location, assuming that you are running the migration tool for an old
configuration, but you could of course give the new location to be saved after
migrating the configuration. I guess we need a little bit more documentation around
the migration tool.
- migration tool mistakenly removes namespaces (destroying
the config), e.g.
value="tns:Receiver"/> à <syn:code
value="tns:Receiver" /> resulting in startup issues
This we need to
fix for this release, I will work on this.
Great, I’d also consider this to be a blocker
as the migration tool can convert a working config into a non-working one. I
have not checked whether a backup is saved somewhere…
- migration tool removes indentation at the beginning of each
This is a known
issue, but I agree needs to be fixed, since it is not critical I would live
with this for the 2.0.0, but definitely a candidate for the next version, so we
need to raise an issue ticket on the synapse JIRA for this.
Agreed, if no one beats me I can do this later
config in single file versus multi file configuration
replacing dummy synapse.xml with old (converted) config is not enough, it
results in errors if main and/or fault sequences are used (as the must exist
only once), sequence files need to be removed
Yes, this I agree
with, but cannot do much I guess again need to explain this on the Upgrading
Is the reason for this, that no concept has
precedence over the other? One can mix both approaches as desired? If so I
fully understand, but documentation is the least we should do. I would also
vote for a prominent link to the Upgrading section in the documentation right
from the front page. May under what’s new or so…
4) Usage of
custom mediators / Site Documentation “Upgrading”
- In the docu
I could not quickly locate a document summarizing the steps which need to be
done to upgrade custom mediators according to API changes (I received some
AbstractMethodError). I did not check the mediator sources against the current
libraries to find out what is no longer compiling…. Anyway a quick summary of
API changes would be nice. As long as I haven’t check the points which do not
compile I cannot say for sure, whether those problems are due to the fact that
public methods not considered to be part of the public API have been used on
our end (which is not unlikely at all).
I agree, will try
to add more on the API changes, at least for the mediator API.
So the Sandesha
module can be easily removed if you are not doing any reliable messaging stuff.
Just need to delete the file from the repository/modules directory. I would
even remove this error message from the custom build of Sandesha2 as we any way
seem to go for the 3rd round of voting. :-)
Eric, I would like
to wait for your feedback to do the 3rd RC. So take your time, but report us
any critical issue as soon as you get to them. May not need to be the complete
list, you can report them one by one as and when you find those, so that we can
fix them if needs to be and be ready for your next round of the feedback. BTW:
must say that we really appreciate your feedback.