Synapse api package

[ant elder <an...@gmail.com>]

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

Re: Synapse api package

[ant elder <an...@gmail.com>]

On 8/7/06, Asankha C. Perera <as...@wso2.com> wrote:

<snip/>

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?


I couldn't think of a good way, having them all in one package makes the
package quite big, but its not obvious how to split them up. Right now the
mediator and config packages also include various support classes, maybe
large single separate packages would be ok if all the support classes were
put somewhere else and the packages contained just mediators and
MediatorFactories.

   ...ant

Re: Synapse api package

["Asankha C. Perera" <as...@wso2.com>]

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: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org