Ant
I agree with your suggestions and would make the changes necessary ASAP
On your last item, do you think we should break the o.a.s.config.xml
classes to be same as the o.a.s.mediators package is structured, or do
you have a suggestion to group the mediators and the config classes?
thanks
asankha
ant elder wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
