On May 30, 2016 8:37 PM, "Hiranya Jayathilaka" <hiranya...@gmail.com> wrote: > > > > On May 30, 2016, at 9:13 AM, Auke Schrijnen <aschrij...@bkwi.nl> wrote: > > > > Hiranya, Andreas, others, > > > > It looks like the mail from Brett worked as a wakeup call, the seems to be more > > activity in the last week than the last year. > > > > I've tried to rebase our patches (based on Synapse 2.1.0) onto the latest trunk > > version, which isn't that easy (the odd project structure doesn't help here, see > > SYNAPSE-888). It needs a lot of work to reshape those patches into small changes > > which could be applied to Synapse. We do have quite some integration tests for > > our services implemented in Synapse and I did found at least one regression > > (Andreas merged the fix, see SYNAPSE-1027). > > > > One thing I noticed was the level of integration of the pass through transport > > with the framework. We ran into similar issues when we started to use Synapse in > > a servlet environment, it seemed that the nhttp transport was the only transport > > which was really supported. > > Supporting servlet containers has always been a challenge to us. Usually all our development and performance optimization efforts are targeted at improving the native transports (first NHTTP, then PT), since we fully understand those implementations. Testing on various servlet container environments requires a lot of time, effort and in some cases access to hard-to-acquire resources. Consequently our support for servlet containers has withered over the years. Even now we have a number of open issues pertaining to various servlet container environments, and fixing them (or even verifying them) could be a massive undertaking.
Do you have an example of a problem that occurs in a servlet container form a specific vendor (as opposed to any servlet container)? > We should discuss whether to continue this support or not in the future. AFAIK WSO2 discontinued servlet container support several years ago for similar reasons. > > > Both Axis2 and Synapse provide various abstraction > > levels and modularity through modules, transports and mediators but the > > boundaries of those abstractions are crossed on many occasions. The root case > > for SYNAPSE-1027 is a crossing of such a boundary in combination with the > > assumption that the pass through transport is used. Unfortunately Synapse lacks > > unit tests which cover those cases and some features are implemented without > > following the architecture of the framework. > > I agree. The PT transport code hasn’t really been reviewed or updated to the level it should have been. As a result the code is pretty much in the same stage it was a couple of years ago. WSO2 folks have been working on it continuously in the meantime, so hopefully, with their help we can whip it into shape. We should also focus on improving our test coverage as you suggest. If we can get multiple committers to look at our code, and provide feedback (perhaps as part of a release cycle), we can identify various abstraction leaks over time and fix them properly. > > > > > Enough complaining... what can I do? Like always, time is a limiting factor. > > First of all we need to upgrade to Synapse trunk. A new Synapse release would > > help a lot here, because it provides a version which doesn't change. Our local > > changes should be rebased on the trunk and sanitized to become patches in Jira. > > As we have a rich set of integration tests for our services we could set up CI > > jobs for testing against the trunk version, although we would use a stable > > version ourselves. Ideally our integration tests are ported to unit or > > integration tests for the Synapse project, but by executing our tests on both > > the latest Synapse release and trunk we can alert the project when our build > > fails and preferably provide patches and tests for the issue. > > +1 > > > > > I presume WSO2 does also have some quality assurance for their Synapse based > > product which could used to improve the quality of the project and according to > > the other thread there are more people who want to contribute. So it looks like > > Synapse can be revived and can become a healthy project. > > > > It would be great if Synapse could release more often and at least follow the > > Axis2 releases. Seeing regular releases, even with only small changes, will > > create a lot more trust in the project. > > I agree. In many ways frequent releases is the only reliable indication of a healthy project. With every release we can improve the code base a little bit. > > > > > Andreas, you are saying the release process needs to be updated to make it > > conform to the current > > requirements for Apache releases. Who is able to do that? Is there anything I > > could do to help in this area? > > Ravi has volunteered to drive this release as the release manager. I believe he’s aware of these requirements. This mostly includes https://issues.apache.org/jira/browse/SYNAPSE-993 > > Thanks, > Hiranya > > > > > Auke > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > > For additional commands, e-mail: dev-h...@synapse.apache.org > > > > -- > Hiranya Jayathilaka > Mayhem Lab/RACE Lab; > Dept. of Computer Science, UCSB; http://cs.ucsb.edu > E-mail: hira...@cs.ucsb.edu; Mobile: +1 (805) 895-7443 > Blog: http://techfeast-hiranya.blogspot.com > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org >
