> On May 30, 2016, at 9:13 AM, Auke Schrijnen <[email protected]> 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. 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: [email protected]
> For additional commands, e-mail: [email protected]
> 

--
Hiranya Jayathilaka
Mayhem Lab/RACE Lab;
Dept. of Computer Science, UCSB;  http://cs.ucsb.edu
E-mail: [email protected];  Mobile: +1 (805) 895-7443
Blog: http://techfeast-hiranya.blogspot.com







---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to