Had a chat with Lakmali about this. As of now this requires a manual publishing of the REST API, but since this is a feature of the registry itself it would be good to ship it published OOTB?
As we are not letting the REST API to be accessed without going through APIM component, the EnableAPIManagement property should be set to true by default as well or it can be ignored altogether? Or we can have a different property to denote any other aspect to be enabled//disabled other than default ones here? Regards, Vijitha. On Sun, Jul 14, 2013 at 9:09 PM, Dinusha Senanayaka <[email protected]>wrote: > Hi Vijitha, > > On Sun, Jul 14, 2013 at 11:13 AM, Vijitha Kumara <[email protected]> wrote: > >> Hi All, >> >> What's the status of this now? Do we have a working use case to be >> reviewed? We might need to finalize & test within next few days. >> > We have committed changes to trunk and have completed basic testing. You > can use trunk GReg pack for testing.. > > Regards, > Dinusha. > >> >> >> >> Regards, >> Vijitha. >> >> >> >> On Thu, Jun 20, 2013 at 11:20 AM, Dinusha Senanayaka <[email protected]>wrote: >> >>> Hi Ragu, >>> >>> On Thu, Jun 20, 2013 at 10:52 AM, Sriragu Arudsothy <[email protected]>wrote: >>> >>>> Hi Lakmali and Dinusha, >>>> >>>> >>>> As you have been completed the tomcat valve, shall I use the >>>> tomcat valve ( kind of interceptor) to test the Registry REST API with the >>>> externally running API Manager instance ? >>>> >>> >>> We are still working on supporting externally running API Manager >>> instance. Will try to finish this by EOT.. But you can use inbuilt api-mgt >>> support to test registry REST API. >>> We have some concerns regarding the registry REST API; >>> 1. We need to have versioning support there. In the current API does not >>> have the versions support.. >>> 2. We need to pass both userName and tenantId as query params, if some >>> user need to use the registry REST API. Having the user name is fine, but >>> tenantId is something external users don't know. So having to pass tenantId >>> to invoke rest API is not correct as we see. >>> eg : >>> http://localhost:9763/resource/comments?path=/_system/governance/apimgt/apiconf.xml&; >>> *username=admin&tenantid=-1234 * >>> >>> Regards, >>> Dinusha. >>> >>>> >>>> Thanks, >>>> Ragu >>>> >>>> >>>> >>>> On Tue, Jun 18, 2013 at 1:20 PM, Dinusha Senanayaka >>>> <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jun 18, 2013 at 12:59 PM, Sriragu Arudsothy >>>>> <[email protected]>wrote: >>>>> >>>>>> Hai Dinusha, >>>>>> >>>>>> At the later part of your answer, you mentioned the >>>>>> how to send the request. Do we have a use case where "without API >>>>>> manager". >>>>>> AFAIR, It has been clearly said during the final discussion , request >>>>>> will >>>>>> be given inbuilt or external APIM. But you mention about without APIM. >>>>>> >>>>> >>>>> But, when it comes to services like DSS, AS etc, we need to have this >>>>> capability. Services, should be able to invoke with api management or >>>>> without api management. yes, for the GRreg (in built apis), manageAPIs >>>>> will >>>>> be always true. >>>>> >>>>> Regards, >>>>> Dinusha. >>>>> >>>>>> >>>>>> Thanks! >>>>>> Ragu >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jun 18, 2013 at 12:31 PM, Dinusha Senanayaka < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Ragu, >>>>>>> >>>>>>> We have wrote a Tomcat Valve which will be act as interceptor for >>>>>>> all incoming requests. There was a need of using >>>>>>> Axis2ConfigurationContextObserver to get the throttling related >>>>>>> properties, >>>>>>> which cannot be done through the CXF hander in GREG REST API. This >>>>>>> tomcat >>>>>>> valve can be used not only by the GReg, also from any other product like >>>>>>> AS, DSS when it comes to manage APIs. >>>>>>> >>>>>>> Also we have been working on, getting publisher and store jaggery >>>>>>> apps into Greg. It was not straight forward because just putting these >>>>>>> apps >>>>>>> into GReg wont work. We had do some code changes in apimgt side to avoid >>>>>>> synapse dependencies. As an example, api-store and publisher need to >>>>>>> have >>>>>>> apimgt-impl component been activated and while this module getting >>>>>>> activated we are creating the tenant artifacts by coping synapse.xml >>>>>>> files >>>>>>> into synapse deployment directories of tenants. We had to customize >>>>>>> apimgt >>>>>>> code that it can identify the where api management is doing and avoid >>>>>>> these >>>>>>> synapse related tasks. >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 18, 2013 at 9:43 AM, Sriragu Arudsothy <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Hai Dinusha and Lakmali, >>>>>>>> >>>>>>>> Please update this mail thread >>>>>>>> that what have you done so far regarding the "Lightweight API manager >>>>>>>> component". >>>>>>>> >>>>>>>> 1) Please let me know the strategy that you are using when >>>>>>>> integrate the external API manager instance. >>>>>>>> >>>>>>>> 2) when an API manager instance externally running, Do we need to >>>>>>>> call the API published at the API gateway? or Does the user call the >>>>>>>> Registry REST API and re-directing the URL to API gateway URL? >>>>>>>> >>>>>>>> 3) If it is a lightweight APIM component which resides within >>>>>>>> G-Reg, Will the request be given to Registry REST API ? >>>>>>>> >>>>>>> Answering to the Q 1, 2, 3: >>>>>>> Always user request will be to the G-Reg API. If the <ManageAPIs> >>>>>>> is enabled then API Management will be handle through the embedded >>>>>>> apimgt >>>>>>> components. And If <ManageAPIs> enabled and if it has been provided >>>>>>> <Store>, <Publisher>, <Gateway>, <KeyManager> urls, then request will be >>>>>>> redirect to the external api manager. Always, request will be first hit >>>>>>> at >>>>>>> the tomcat valve that we have added, logic will be reside in this valve >>>>>>> , >>>>>>> how api management is handling, whether inbuilt, external or without api >>>>>>> management. >>>>>>> >>>>>>> Regards, >>>>>>> Dinusha. >>>>>>> >>>>>>>> >>>>>>>> What has to be done to complete it ? >>>>>>>> >>>>>>>> Because the Greg has a strict dead line to finish off by next week >>>>>>>> ? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Ragu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jun 10, 2013 at 6:31 PM, Sriragu Arudsothy < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hai Sanjeewa..! >>>>>>>>> >>>>>>>>> We are having a strategic discussion that >>>>>>>>> how to include the API publisher/ store jag apps to other products. >>>>>>>>> Therefore, I will update this thread after the discussion...! As far >>>>>>>>> as I >>>>>>>>> understand, there will be single interceptor which decides the >>>>>>>>> processing >>>>>>>>> path according to the <manageAPIs> property value. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Ragu >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jun 10, 2013 at 6:03 PM, Sriragu Arudsothy < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hai Lakmali..! >>>>>>>>>> >>>>>>>>>> Yes, the above link does not work...! I >>>>>>>>>> moved the user token generation menu under the "Resources" menu in >>>>>>>>>> order to >>>>>>>>>> appear for Greg. Therefore the existing doc won't work. Also these >>>>>>>>>> changes >>>>>>>>>> have not yet been committed. I will give you , the locally built >>>>>>>>>> latest >>>>>>>>>> Greg 4.6.0 pack which has every thing. You can also try out some >>>>>>>>>> samples. >>>>>>>>>> When you get the access token via that option , that access token >>>>>>>>>> will be >>>>>>>>>> based on "Client_Credentials" grant type. Since the API store jag >>>>>>>>>> app will >>>>>>>>>> be there anyway to incorporate the light weight APIM component. >>>>>>>>>> Therefore >>>>>>>>>> the users are required to generate the access token via store when >>>>>>>>>> the >>>>>>>>>> <manage APIs> property set to true. Therefore I have to update the >>>>>>>>>> doc for >>>>>>>>>> generating the access token for either <manageApis> property set to >>>>>>>>>> true or >>>>>>>>>> false. >>>>>>>>>> >>>>>>>>>> I will update the Doc as quickly as possible. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> Ragu >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Jun 10, 2013 at 4:45 PM, Sanjeewa Malalgoda < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Jun 10, 2013 at 4:08 PM, Dinusha Senanayaka < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> This is what we are going to add from the APIM side. >>>>>>>>>>>> >>>>>>>>>>>> 1) We will be exposing current api manager handlers related >>>>>>>>>>>> functionalities as some common packages. So this bundle can be >>>>>>>>>>>> included >>>>>>>>>>>> into any of products to get API Management without using external >>>>>>>>>>>> API >>>>>>>>>>>> Manager. (i.e APIAuthenticationHandler, APIThrottleHandler and >>>>>>>>>>>> APIMgtUsageHandler) >>>>>>>>>>>> >>>>>>>>>>>> 2) There will be a new parameter added to carbon.xml to check >>>>>>>>>>>> whether APIManagement is enable or not. >>>>>>>>>>>> <ManageAPIs>true/false<ManageAPIs> >>>>>>>>>>>> >>>>>>>>>>>> 3) There will be a interceptor which hit first and invoke the >>>>>>>>>>>> API Management functionalities when the above parameter is set to >>>>>>>>>>>> true. >>>>>>>>>>>> Depending on the service type, aixs2 or registry api etc, this >>>>>>>>>>>> interceptor >>>>>>>>>>>> may vary. >>>>>>>>>>>> When this comes to registry, we can call this api-management >>>>>>>>>>>> functionalities that we are going to expose through new package >>>>>>>>>>>> from the >>>>>>>>>>>> JAXWS web app that Ragu has created to expose the registry api. >>>>>>>>>>>> Since >>>>>>>>>>>> generic store feature is not going to release with the up coming >>>>>>>>>>>> registry >>>>>>>>>>>> release, we may need to include APIM Store jaggery app as well in >>>>>>>>>>>> to GReg. >>>>>>>>>>>> >>>>>>>>>>> Just to clarify. With this model where we can create >>>>>>>>>>> APIs, subscriptions and generate tokens? Do we provide some UI >>>>>>>>>>> capability >>>>>>>>>>> for this? Do we have single interceptor which handles all requests? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sanjeewa. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Dinusha. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jun 10, 2013 at 11:41 AM, Sriragu Arudsothy < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hai Lalaji, Dinusha..! >>>>>>>>>>>>> >>>>>>>>>>>>> We have had a discussion >>>>>>>>>>>>> about the Light weight APIM component for other wso2 products as >>>>>>>>>>>>> well as >>>>>>>>>>>>> How to fit that to the Registry REST API. According to the last >>>>>>>>>>>>> discussion >>>>>>>>>>>>> with Lalaji, Dinusha and Lakmali We derived some points which I >>>>>>>>>>>>> would like >>>>>>>>>>>>> to mention..! Still there is some ambiguity at the APIM side. >>>>>>>>>>>>> >>>>>>>>>>>>> 1) The current implemetation of the registry REST API requires >>>>>>>>>>>>> the APIM has to be running as a separate instance while having a >>>>>>>>>>>>> configuration file (.xml) has the API manager url endpoints in >>>>>>>>>>>>> it. The >>>>>>>>>>>>> above config file was located at the Greg_Home/repository/conf. >>>>>>>>>>>>> >>>>>>>>>>>>> 2) The light weight API manager component will reside at the >>>>>>>>>>>>> Greg. The flow of request goes as below, >>>>>>>>>>>>> >>>>>>>>>>>>> Rest Client request-----> Request filter/Some filter mechanism >>>>>>>>>>>>> ------>light weight APIM ------> Registry REST API ---->Response >>>>>>>>>>>>> back to >>>>>>>>>>>>> Client. >>>>>>>>>>>>> >>>>>>>>>>>>> The above path will be executed if the APIM enabled property >>>>>>>>>>>>> set to true at the config file...! >>>>>>>>>>>>> >>>>>>>>>>>>> Otherwise it request filter assumes that the request should be >>>>>>>>>>>>> processed without APIM. Request filter executes the OAuth >>>>>>>>>>>>> validation logic >>>>>>>>>>>>> at the Greg REST API and proceeds to resource . Therefore the >>>>>>>>>>>>> Request >>>>>>>>>>>>> filter will be functioning as a centralized routing element >>>>>>>>>>>>> decides whether >>>>>>>>>>>>> the request to be processed via light weight APIM comp or alone >>>>>>>>>>>>> at the Greg >>>>>>>>>>>>> REST API. >>>>>>>>>>>>> >>>>>>>>>>>>> @Lalaji and Dinusha please add anything if I miss anything. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> Ragu >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jun 6, 2013 at 12:01 PM, Sriragu Arudsothy < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hai All, >>>>>>>>>>>>>> >>>>>>>>>>>>>> First of all, I will explain the architecture of >>>>>>>>>>>>>> the REST API implementation. The Registry REST API has two mode >>>>>>>>>>>>>> of >>>>>>>>>>>>>> functionality. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) Standalone mode - >>>>>>>>>>>>>> >>>>>>>>>>>>>> Straight access to Registry REST API. This has been done and >>>>>>>>>>>>>> working fine. In this case Registry provide a way to generate >>>>>>>>>>>>>> the OAuth >>>>>>>>>>>>>> Access token for users to access the resources. Therefore the >>>>>>>>>>>>>> REST calls >>>>>>>>>>>>>> can be made from any REST client with an access token to access >>>>>>>>>>>>>> the >>>>>>>>>>>>>> resources. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) With API Manager Mode - >>>>>>>>>>>>>> >>>>>>>>>>>>>> This means the access to Registry REST API with the >>>>>>>>>>>>>> Externally running API manager instance. In here, the admin or >>>>>>>>>>>>>> any >>>>>>>>>>>>>> responsible person will publish the REST API via API publisher. >>>>>>>>>>>>>> Therefore >>>>>>>>>>>>>> the REST API would be available for subscriber / endusers. Once >>>>>>>>>>>>>> the access >>>>>>>>>>>>>> token has been generated, user will be able to access the >>>>>>>>>>>>>> Registry >>>>>>>>>>>>>> Resources. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In this mode, There are 2 ways in which I have implemented >>>>>>>>>>>>>> the REST API invocation process. This is explained as below. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1 >> REST client ----> API gateway(REST API published at the >>>>>>>>>>>>>> APIM) ---->Registry REST API ----> Registry Resource ----> >>>>>>>>>>>>>> Response go to >>>>>>>>>>>>>> REST client. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The above implementation works fine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2 >> REST Client -----> Registry REST API ----> Call the REST >>>>>>>>>>>>>> endpoint at the APIM ----> return call from APIM to Registry >>>>>>>>>>>>>> REST API ----> >>>>>>>>>>>>>> Registry Resource ----> Response back to REST client. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The above approach, I have the an issue to pass the payload >>>>>>>>>>>>>> from Registry REST API to APIM. I have designed the REST API in >>>>>>>>>>>>>> CXF/ >>>>>>>>>>>>>> JAx-Rs. The apache CXF Jax-Rs implementation provide a Request >>>>>>>>>>>>>> Handler >>>>>>>>>>>>>> which is an interceptor for the incoming requests. Therefore any >>>>>>>>>>>>>> request >>>>>>>>>>>>>> made from REST client to Registry REST API will hit the Request >>>>>>>>>>>>>> Handler >>>>>>>>>>>>>> First. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Therefore, when the request go to the handler, it will check >>>>>>>>>>>>>> whether the request comes from APIM or Straight from the Client. >>>>>>>>>>>>>> If it >>>>>>>>>>>>>> comes from the client it will call the REST API endpoint at the >>>>>>>>>>>>>> APIM via an >>>>>>>>>>>>>> apache HttpClient. Therefore when I call it, I have to extract >>>>>>>>>>>>>> the access >>>>>>>>>>>>>> token, queryParam, payload..etc from REST client's request and >>>>>>>>>>>>>> add it to >>>>>>>>>>>>>> the request given to APIM. But I am able to extract the access >>>>>>>>>>>>>> token, >>>>>>>>>>>>>> queryparam and add it to HttpMethod and call the APIM. Request >>>>>>>>>>>>>> Handler >>>>>>>>>>>>>> seems that does not have a way to extract the payload ( >>>>>>>>>>>>>> POST/PUT). >>>>>>>>>>>>>> Therefore unable to pass the payload to the REGISTRY REST API. >>>>>>>>>>>>>> That is why >>>>>>>>>>>>>> GET and DELETE requests are working fine in the second approach >>>>>>>>>>>>>> since those >>>>>>>>>>>>>> do not require the payload. BUT POST/PUT requests fail to >>>>>>>>>>>>>> proceed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Therefore The CXF JAX-RS Request Handler has both the >>>>>>>>>>>>>> Standalone Mode and APIM mode execution. Therefore the >>>>>>>>>>>>>> standalone mode is >>>>>>>>>>>>>> working fine. But Which approach to be selected regarding the >>>>>>>>>>>>>> APIM mode to >>>>>>>>>>>>>> put it in the request handler class. Since there is an issue in >>>>>>>>>>>>>> Approach 2 >>>>>>>>>>>>>> @ APIM mode, It went to approach 1. According to the approach 1 >>>>>>>>>>>>>> the code >>>>>>>>>>>>>> will be cleaner than approach 2. >>>>>>>>>>>>>> >>>>>>>>>>>>>> *According to Approach 1 @APIM mode the example Request URL >>>>>>>>>>>>>> will be,* >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://{ipaddress}:8280/{REST API context >>>>>>>>>>>>>> @APIM}/{version}/comments?path=/sample.xml. >>>>>>>>>>>>>> >>>>>>>>>>>>>> *in Standalone mode: >>>>>>>>>>>>>> * >>>>>>>>>>>>>> http:{IP address}:{greg http port}/{rest api context @ >>>>>>>>>>>>>> greg}/comments?path=/sample.xml. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The APIM team already given their words to derive an >>>>>>>>>>>>>> integrate able APIM solution for other WSO2 products. Meanwhile >>>>>>>>>>>>>> we heard >>>>>>>>>>>>>> that APIM team working on that too. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Few days ago, Had a chat with APIM guys, They said that API >>>>>>>>>>>>>> publisher and API store will be there as it is. Therefore >>>>>>>>>>>>>> whoever wants to >>>>>>>>>>>>>> publish an API have login to the API publisher and publish an >>>>>>>>>>>>>> API. This can >>>>>>>>>>>>>> not be done automatically during the server starts up. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is all about the integration part of REST API with API >>>>>>>>>>>>>> Manager. @APIM please let us know the current stage of your >>>>>>>>>>>>>> solution. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> Ragu >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Dinusha Dilrukshi >>>>>>>>>>>> Senior Software Engineer >>>>>>>>>>>> WSO2 Inc.: http://wso2.com/ >>>>>>>>>>>> Mobile: +94725255071 >>>>>>>>>>>> Blog: http://dinushasblog.blogspot.com/ >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> * >>>>>>>>>>> * >>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>> WSO2 Inc. >>>>>>>>>>> Mobile : +94713068779 >>>>>>>>>>> >>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dinusha Dilrukshi >>>>>>> Senior Software Engineer >>>>>>> WSO2 Inc.: http://wso2.com/ >>>>>>> Mobile: +94725255071 >>>>>>> Blog: http://dinushasblog.blogspot.com/ >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dinusha Dilrukshi >>>>> Senior Software Engineer >>>>> WSO2 Inc.: http://wso2.com/ >>>>> Mobile: +94725255071 >>>>> Blog: http://dinushasblog.blogspot.com/ >>>>> >>>> >>>> >>> >>> >>> -- >>> Dinusha Dilrukshi >>> Senior Software Engineer >>> WSO2 Inc.: http://wso2.com/ >>> Mobile: +94725255071 >>> Blog: http://dinushasblog.blogspot.com/ >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Vijitha Kumara >> Senior Software Engineer; WSO2, Inc.; http://wso2.com/ >> email: [email protected] >> >> >> Lean . Enterprise . Middleware >> > > > > -- > Dinusha Dilrukshi > Senior Software Engineer > WSO2 Inc.: http://wso2.com/ > Mobile: +94725255071 > Blog: http://dinushasblog.blogspot.com/ > -- Vijitha Kumara Senior Software Engineer; WSO2, Inc.; http://wso2.com/ email: [email protected] Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
