I was looking at the organization of the Synapse code and wondered if it could be tidied up a bit. It looks pretty good but moving some packages and classes around I think could make it more clear and simple.
For example, there could be some moving around of the classes in the packages
org.apache.synapse and org.apache.synapse.api. It seems odd to me that there's an API package which has the Mediator interface but that the MessageContext is not in the API package. Also should the Filter and List mediator interfaces be in the API package? Could they be move out to one of the mediator packages?
Not sure the HeaderType class should be in the root o.a.synapse package, but actually is this class really needed at all? Its only used in two places, GetPropertyFunction and HeaderMediator. It seems like a complicated way for the HeaderMediator to be able to use a case statement instead of doing if-then-else on Strings which works just fine for the GetPropertyFunction Function. So could all the WSA String constants in HeaderType just be moved to
o.a.s.Constants, HeaderMediator change to compare Strings the way GetPropertyFunction does it, and the HeaderType class deleted?
In the Util class how about moving the methods getStringValue and setErrorInformation to the MessageContext? And then renaming Utils to
o.a.s.utils.OMElementUtils (or get the AXIOM guys to include these util methods somewhere?)
I wondered about moving MessageContext to the api package, but it exposes the SynapseEnvironment and SynaspeConfiguration, and from those you get at things like the Registry. There could be specific SPI packages created with interfaces for all those things, but that seems like overkill, so maybe just get rid of the API package altogether and move the Mediator interface up to
o.a.synapse?
With all those changes it makes the root package o.a.Syanpse clean and simple and makes it obvious that the Mediator and MessageContext are the interesting classes.
org.apache.synapse:
- Constants
- Mediator
- MessageContext
- SynapseException
Where to put the FilterMediator and ListMedaitor that are currently in the api pkg? Well there's so many packages for mediators: o.a.s.mediators, o.a.s.mediators.base
, o.a.s.mediators.builtin, o.a.s.mediators.ext, o.a.s.mediators.filters, o.a.s.mediators.transform. I don't really understand what the difference of all those is? Compare that with the mediator XML config package o.a.s.config.xml
which has all those mediator config classes in one pakage. Thats getting quite big though so maybe it needs to be broken up a bit. Could there be some rationalization for all these mediator impls and their config classes somehow?
...ant
- Synapse api package ant elder
- Re: Synapse api package Asankha C. Perera
- Re: Synapse api package ant elder
