HI Eric, First of all thanks a lot. See my comments inline.
On Thu, Dec 9, 2010 at 2:46 PM, Hubert, Eric <eric.hub...@foxmobile.com>wrote: > Hi all, > > > > here are my first test observations – let’s state it like that. So far I > think it is best to simply bring them up to the list, so we can sort out > which of those are to be considered expected behaviour and are somewhere > documented and which are issues which should be fixed according to their > priority (which also needs to be determined). > +1 > > > 1) Synapse startup test with custom 1.2 config > > - config has been put into repository/conf/synapse-config as it seems to > got ignored in repository/conf > 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 synapse. :-( > - Unexpected 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 return value > 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? > > > 2) Migration Tool > > - executing 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. > - old copy copied there and restarted > > - migration tool modifies config > > - Unexpected behaviour: > > - 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. > <code xmlns:tns="http://www.w3.org/2003/05/soap-envelope"; > 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. > - migration tool removes indentation at the beginning of each xml element > 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. > > > 3) Traditional config in single file versus multi file configuration > > - Unexpected behaviour: > > - 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 > from subdirectories > Yes, this I agree with, but cannot do much I guess again need to explain this on the Upgrading guide > > > 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. > > > Once I find the time, I will move on with my tests (probably this late > evening, CET)… > +1 Ruwan > > > Hope the feedback is still of help… > > > > Regards, > > Eric > > > > > ------------------------------ > > *From:* Ruwan Linton [mailto:ruwan.lin...@gmail.com] > *Sent:* Thursday, December 09, 2010 7:04 AM > > *To:* dev@synapse.apache.org > *Subject:* Re: [VOTE] Release Synapse-2.0.0 (Take2) > > > > 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. > > > > Thanks, > > Ruwan > -- Ruwan Linton Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
