Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant
The header name "Authorization" is what commonly used by all the clients/proxies. So we defining our own way for the "header name" is what my concern is. If we define such customized name, will the external clients adhere to that? The spec says that the common format used is Authorization = [1] So shouldn't we use a customized way or scheme for the part only, to identify tenant specific tokens (which is the requirement for $subject), but not change the header name itself? Some discussions related to this in SO - https://stackoverflow.com/questions/42574022/custom-authorization-header https://stackoverflow.com/questions/8463809/customize-the-authorization-http-header Thanks, [1] https://tools.ietf.org/html/rfc7235#section-4.2 On Fri, Dec 1, 2017 at 9:35 PM, Dulanja Liyanage <dula...@wso2.com> wrote: > "The OAuth 2.0 Authorization Framework: Bearer Token Usage" spec [1] > mentions 3 ways the token could be sent to the Resource Server - APIM > Gateway in this case: > >- Authorization Request Header Field >- Form-Encoded Body Parameter >- URI Query Parameter > > It doesn't seem to mandate that other header names couldn't be used. Since > we anyway use the recommended "Authorization" header by default, I don't > see a problem in this. > > [1] https://tools.ietf.org/html/rfc6750#page-4 > > On Thu, Nov 30, 2017 at 3:50 PM, Kishanthan Thangarajah < > kishant...@wso2.com> wrote: > >> Is this approach (custom authorization header field) allowed at OAuth2 >> spec level? I mean, is this something we can customize/define and use it >> for our own, and also in accordance with the spec? >> >> Thanks, >> >> On Thu, Nov 30, 2017 at 10:57 AM, Viduranga Gunarathne < >> vidura...@wso2.com> wrote: >> >>> Hi, >>> >>> @Prasanna, >>> No we do not need to restart the server. Since this configuration is >>> shipped with the tenant-conf.json, it will be automatically added to each >>> of the created tenant configs in the registry, whenever a new tenant is >>> created. Even for an existing tenant it can be added manually to the >>> respective tenant config from the registry. A tenant only has to change the >>> config in the registry to change the header name and save it back to >>> registry. So when a new API is published, the custom header name will be >>> read from the specific tenant config in the registry and added to the >>> synapse config so that it will be deployed in the Gateway. >>> >>> @Chamalee, >>> Yes, it will allow us to pass a custom header field instead of >>> "Authorization" to the back end for authorization. And since this config is >>> deployed in the gateway through the synapse config, once a request is >>> received it can check for the specific header field for the authorization >>> token. >>> >>> The use cases for this are as follows: >>> >>> i) In a scenario where both the back end and the API-M requests >>> authorization tokens. >>> If the back end already expects an authorization token by the name >>> "Authorization", then there will be a complication when sending two tokens >>> by the same name; one for the back end and he other for APIM. So the >>> authorization header name of APIM should be changed. >>> >>> ii) Existing client apps that communicate with a back end with >>> authorization tokens such as "TOKEN", "KEY". >>> When APIM is introduced to an existing system where client apps used to >>> communicate with the back end with their own authorizations tokens such as >>> "TOKEN", "KEY" etc. , the client apps will have to be modified to send >>> "Authorization" instead. This can be avoided with customizing the >>> authorization header. >>> >>> iii) In the APIM cloud, each tenant will be able to define their own >>> authorization header field. >>> >>> Thanks, >>> Viduranga. >>> >>> On Mon, Nov 27, 2017 at 10:21 PM, Chamalee De Silva <chama...@wso2.com> >>> wrote: >>> >>>> Hi Viduranga, >>>> >>>> As per this design, >>>> Assuming that for all tenants the tenant-config is having the >>>> CustomAuthHeader value and RemoveOAuthHeadersFromOutMessage is >>>> configured as false, >>>> it allows us to pass a custom header field instead of Authorization >>>> header to the backend for the authorization. >>>> >>>> Can you elaborat
Re: [Architecture] [APIM] [C4] Custom header field for OAuth2 token per tenant
;>>>>> >>>>>>>>>Eg: >>>>>>>>> >>>>>>>>> Tenant 1 : hr.lk --> "HR_Auth : Bearer >>>>>>>>> NtBQkXoKElu0H1a1fQ0DWfo6IX4a" >>>>>>>>> >>>>>>>>> Tenant 2 : eng.lk --> "ENG_Auth : Bearer >>>>>>>>> NtBQkXoKElu0H1a1fQ0DWfo6IX4a" >>>>>>>>> >>>>>>>>> >>>>>>>>>NB: This feature also supports the current implementation of >>>>>>>>> "Authorization" as the header field, so that it doesn't affect the >>>>>>>>> existing >>>>>>>>> API-Ms in production. >>>>>>>>> >>>>>>>>> >>>>>>>>> ii) In API-M 2.1.0 there is a feature to restrict the access >>>>>>>>> token, that is being sent in the request, to be passed through to the >>>>>>>>> production endpoint from the Gateway. The configuration relevant to >>>>>>>>> this is >>>>>>>>> in the "api-manager.xml" and it is as follows; >>>>>>>>> >>>>>>>>> * >>>>>>>>> true* >>>>>>>>> >>>>>>>>> If the value is set to *true *then the Gateway will not pass >>>>>>>>> the access token to the back end and if it's *false*, then it >>>>>>>>> will. Since this configuration resides in the *"api-manager.xml"*, >>>>>>>>> it applies in a "per server" basis. The proposal is to migrate it to >>>>>>>>> the *"tenant-conf.json" >>>>>>>>> *so that this configuration can be applied in a "per >>>>>>>>> tenant" basis. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *Solutions:* >>>>>>>>> The design of the proposed solutions for the two problems are as >>>>>>>>> follows: >>>>>>>>> >>>>>>>>> i) Proposed workflow for custom header field: >>>>>>>>> >>>>>>>>> a) Read a configuration from the "tenant-conf.json" for a >>>>>>>>> customized OAuth2 header field. >>>>>>>>> b) Insert the config into the synapse config file that is >>>>>>>>> generated once an API is published, so that it gets deployed in the >>>>>>>>> Gateway. >>>>>>>>> c) Use the custom header when checking the access token from >>>>>>>>> "APIAuthenticationHandler" for authentication. >>>>>>>>> >>>>>>>>> d) If no configuration exists in the "tenant-conf.json", then >>>>>>>>> check for a config in "api-manager.xml" and follow step (b) and (c). >>>>>>>>> This >>>>>>>>> config will act as global config for the server. >>>>>>>>> >>>>>>>>> e) If no configuraton exists in the api-manager.xml then the >>>>>>>>> existing workflow will execute using the "Authorization" header field. >>>>>>>>> >>>>>>>>> >>>>>>>>> ii) Proposed workflow for restricting the access token from being >>>>>>>>> passed to the backend. >>>>>>>>> >>>>>>>>> a) Read the "RemoveOAuthHeadersFromOutMessage" config from the >>>>>>>>> "tenant-conf.json" >>>>>>>>> >>>>>>>>> b) If no config exists in tenant-conf.json, then read it from the >>>>>>>>> "api-manager.xml" >>>>>>>>> >>>>>>>>> >>>>>>>>> Any ideas and suggestions are highly appreciated! >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Viduranga. >>>>>>>>> >>>>>>>>> [1] https://docs.wso2.com/display/AM210/Working+with+Access+Tokens >>>>>>>>> -- >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> *Viduranga Gunarathne* >>>>>>>>> >>>>>>>>> *Software Engineer Intern* >>>>>>>>> >>>>>>>>> >>>>>>>>> *WSO2* >>>>>>>>> Email : vidura...@wso2.com >>>>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>>>> Web : http://wso2.com >>>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nuwan Dias >>>>>>>> >>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>> email : nuw...@wso2.com >>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> *Viduranga Gunarathne* >>>>>>> >>>>>>> *Software Engineer Intern* >>>>>>> >>>>>>> >>>>>>> *WSO2* >>>>>>> Email : vidura...@wso2.com >>>>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>>>> Web : http://wso2.com >>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>> >>>>>>> ___ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dinusha Dissanayake >>>>>> Software Engineer >>>>>> WSO2 Inc >>>>>> Mobile: +94712939439 <+94%2071%20293%209439> >>>>>> <https://wso2.com/signature> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> *Viduranga Gunarathne* >>>>> >>>>> *Software Engineer Intern* >>>>> >>>>> >>>>> *WSO2* >>>>> Email : vidura...@wso2.com >>>>> Mobile : +94712437484 <+94%2071%20243%207484> >>>>> Web : http://wso2.com >>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Chamin Dias >>>> Mobile : 0716097455 >>>> Email : cham...@wso2.com >>>> LinkedIn : https://www.linkedin.com/in/chamindias >>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Thanks & Regards, >> >> *Chamalee De Silva* >> Software Engineer >> *WS**O2* Inc. :http://wso2.com/ >> >> Office :- *+94 11 2145345 <%2B94%2011%202145345>* >> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942* >> >> > > > -- > Regards, > > *Viduranga Gunarathne* > > *Software Engineer Intern* > > > *WSO2* > Email : vidura...@wso2.com > Mobile : +94712437484 <+94%2071%20243%207484> > Web : http://wso2.com > [image: https://wso2.com/signature] <https://wso2.com/signature> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 <+94%2077%20342%206635> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Skipping service registrations from Startup Order Resolver in ther server startup
entation for more information.
>
> Suggesting Solution:
>
> In the offline discussed had with Jayanga & ThusithaD, following was
> suggested.
>
> There should be a way to explicitly tell the Startup Order Resolver to
> ignore an OSGI service registrations. This can be achieved with properties.
> When registering a capability via the BundleContext, a property (e.g.
> "SKIP_STARTUP_RESOLVER") can be set to true. When tracking services in the
> Startup Order Resolver, it can skip the services that has the said property.
>
> Dictionary<String, String> dictionary = new Hashtable<>();
> dictionary.put("CHANNEL_ID", httpTransport.getId());
> dictionary.put("contextPath", appContextPath);
> *dictionary.put("SKIP_STARTUP_RESOLVER", "true");*
> bundleContext.registerService(Microservice.class, new
> WebappMicroservice(), dictionary);
>
>
> WDYT?
>
> [1] https://github.com/wso2/msf4j/blob/v2.4.0-m1/core/pom.xml#L366
>
> Thanks.
>
> --
> Sajith Janaprasad Ariyarathna
> Senior Software Engineer; WSO2, Inc.; http://wso2.com/
> <https://wso2.com/signature>
>
--
*Kishanthan Thangarajah*
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Folder Structure for C5 based MB
With this approach, all the components required for the product will be in the proposed product repo and any changes to components (bug fixes, etc), will require a product release. You also have to use the new product directory structure proposed for C5 based servers. And don't use carbon.product file, unless it is necessary. Not to have a "carbon.prodcut" is supported with the latest carbon feature plugin. Otherwise, you can't automate the release with CI/CD. if required. Thanks, On Thu, Apr 27, 2017 at 11:32 AM, Eranda Rajapakshe <eran...@wso2.com> wrote: > Hi, HasithaD and I are working on bootstrapping the C5 based Message > Broker product. > > In the current version of WSO2 Message broker (3.x) we have following 3 > repos. > > >1. > >Andes - contains the messaging core, apache qpid fork and JMX >monitoring objects. >2. > >Carbon-business-messaging - contains admin services, wraps andes as a >osgi service, and the UI impl. >3. > >Product-mb - contains test cases, and distribution configurations. > > > For MB 4x, we have come up with a more unified structure based on a single > repo (refer [2] as an example). The intention here is to reduce build and > maintenance complexity. However, if there is a need to use separate > components/features within MB into other products, we need to go for > separate repos as and when required. > > We will be working on product-mb/4.x.x branch [1]. Please let us know any > suggestion and comments on this. > > [1]. https://github.com/wso2/product-mb/tree/4.x.x > > [2]. > > product-mb > > ├── components > > │ ├── org.wso2.carbon.andes > > │ ├── org.wso2.carbon.mb.services > > │ ├── org.wso2.carbon.mb.ui > > │ └── ….. > > ├── features > > │ ├── org.wso2.carbon.andes.feature > > │ ├── org.wso2.carbon.mb.services.feature > > │ ├── org.wso2.carbon.mb.ui.feature > > │ └── …... > > ├── pom.xml > > ├── LICENSE.txt > > ├── README.md > > └── product > > ├── carbon-home > > │ └── README.md > > ├── carbon.product > > ├── pom.xml > > └── src > > └── assembly > > ├── bin.xml > └── filter.properties > > Thanks, > -- > *Eranda Rajapakshe* > Software Engineer > WSO2 Inc. > Mobile : +94784822608 > > ___ > Dev mailing list > d...@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] C5 Fixing the StartupOrderResolver race condition
Hi Jayanga,
As we spoke offline, did we check on the possibility of using service
EvenHook instead of the above "cache" ? Also how the internals work when
events are delivered in an order (trackers vs service component
references)?
Thanks,
On Wed, Mar 22, 2017 at 6:37 PM, Jayanga Dissanayake <jaya...@wso2.com>
wrote:
> Hi All,
>
> In the C5 Carbon Kernel, we introduced a new feature call
> StartupOrderResolver. The main idea is to overcome some of the limitation
> we have in the cardinality of OSGi Service Components and to have implicit
> dependencies among the components. You can find more information on the
> design/implementation in [1] and [2].
>
> In the recent testing, we came across a very rare race condition in this
> implementation which is explained below.
>
>
>
>
> Let's assume there is Component (DeploymentMgtComponent) that is using
> StartupOrderResolver, needs to wait until all the Deployment services are
> available.
>
> 1) The Happy Path
> i) A deployment service registers with the OSGi registry (1)
> ii) OSGi Registry notifies the ServiceComponent (2a)
> iii) OSGi Registry notifies the ServiceTracker of StartupOrderResolver (2b)
> iv) StartupOrderResolverUpdates its ServiceMetadata
> (v) The timer triggers, if all the required capabilities are ready, notify
> the component (3)
>
> 2) Problematic Path
> i) A deployment service registers with the OSGi registry (1)
> ii) OSGi Registry notifies the ServiceTracker of StartupOrderResolver (2b)
> iii) StartupOrderResolverUpdates its ServiceMetadata
> iv) The timer triggers, if all the required capabilities are ready, notify
> the component (3)
> v) OSGi Registry notifies the ServiceComponent (2a)
>
> In the problematic path, onAllRequiredCapabilitiesAvailable() method is
> called before a reference to the Deployment service is received via the
> OSGi registry.
>
> The fix is to delay the method call onAllRequiredCapabilitiesAvailable()
> until all the service references are received by the ServiceComponet. But
> there is no OOB way of detecting from the outside, whether a particular
> component has received a service reference or not.
>
> Hence I came up with the below-mentioned solution, In which I added a new
> "StartupServiceCache" and changed the StartupOrder pending capability
> detecting logic to use the StartupServiceCache to identify the services
> that are already known by the Component.
>
> With this approach, if a ServiceComponent developer wants to rely on
> StartupOrderResolver, he will have to follow the same old way and have an
> additional entry in the @Reference method in the service component
>
> e.g:
> StartupServiceUtils.updateServiceCache("carbon-deployment-mgt",
> Deployment.class, deployment);
>
>
>
>
>
> The proposed solution fixes the issue. With this solution, the developer
> will have to add another one entry in the ServiceComponent, which I believe
> ok as the developer anyway be putting additional entries in the Components
> and Services to make it incorporate with old StartupOrderResolver.
>
> Anyway, I am looking into other possibilities whether we could get rid of
> this additional entry.
>
> Any idea/suggestion on this regard is highly appreciated.
>
> [1] https://medium.com/@sameera.jayasoma/startup-order-resol
> ving-mechanisms-in-osgi-48aecde06389#.vn6p146ts
> [2] https://medium.com/@sameera.jayasoma/resolving-startup-o
> rder-of-carbon-components-in-wso2-carbon-5-0-0-497fe3287e67#.drybgj29a
>
> Thanks,
> *Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: jaya...@wso2.com
> mobile: +94772207259 <+94%2077%20220%207259>
> <http://wso2.com/signature>
>
--
*Kishanthan Thangarajah*
Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635 <+94%2077%20342%206635>
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration
Could you explain the advantage of this proposed approach based on OSGi vs non-OSGi mode of execution? On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara <vidu...@wso2.com> wrote: > Hi All, > > An example for a secure vault YAML configuration file is as shown below > according to the current implementation. > > secretRepository: > type: org.wso2.carbon.kernel.securevault.repository. > DefaultSecretRepository > parameters: > privateKeyAlias: wso2carbon > keystoreLocation: resources/security/wso2carbon.jks > masterKeyReader: > type: org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyReader > > However, according to the discussion made in [1] > <http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html> > , we decided to move Carbon Secure Vault out of Carbon Kernel for the > specified reasons in [1] > <http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html>. > According to this change, in OSGi mode the Secret repository and the > master key reader will be an implementation of the specified classes ( > org.wso2.carbon.kernel.securevault.repository.DefaultSecretRepository and > org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyReader) and > will be registered via the Secure Vault Component while in standalone > mode the secret repository and master key reader will be instances of the > specified classes and will be created using the class.forName() method. > > According to this implementation, it was decided to delegate providing > other file paths (secret.properties, master-key.yaml) to relevant > implementation classes because other file paths (secret.properties, > master-key.yaml) are bound to the relevant implementation. However, with > this approach, we are forced to check whether the code is being executed in > OSGi mode or non-OSGi mode in order to provide the correct location of the > file paths (secret.properties, master-key.yaml). > > *Suggestion:* > > secretRepository: > type: org.wso2.carbon.secvault.securevault.repository. > DefaultSecretRepository > parameters: > privateKeyAlias: wso2carbon > keystoreLocation: securevault/resources/security/wso2carbon.jks > secretProperties: securevault/resources/security/secrets.properties > masterKeyReader: > type: org.wso2.carbon.secvault.securevault.utils. > DefaultHardCodedMasterKeyReader > parameters: > masterKeyFile: securevault/resources/security/master-keys.yaml > > > If we could add the highlighted properties to the secure vault YAML > configuration file specifying the location of the master-keys.yaml and > secrets.properties, we only need to check whether the code is being > executed in OSGi mode or non-OSGi mode once at the time of secure vault > initialisation. > > WDYT? > > [1] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate > Repositories (Removing from Kernel) > <http://wso2-oxygen-tank.10903.n7.nabble.com/C5-Moving-Carbon-Configuration-and-Carbon-Sec-Vault-to-2-Separate-Repositories-Removing-from-Kernel-td146953.html> > > > Best Regards, > > *Vidura Nanayakkara* > Software Engineer > > Email : vidu...@wso2.com > Mobile : +94 (0) 717 919277 <+94%2071%20791%209277> > Web : http://wso2.com > Blog : https://medium.com/@viduran <http://wso2.com/> > Twitter : http://twitter.com/viduranana > LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara > <http://wso2.com/> > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template
On Mon, Jan 23, 2017 at 11:49 AM, Dilan Udara Ariyaratne <dil...@wso2.com> wrote: > Hi Azeez, > > Even with the pom based approach (as noted by Kishanthan), we do not have > the luxury of totally getting rid of this file, carbon.product > I believe this is only needed at product build time, so we do not need to keep a file in the repo but only create the file during build time and then delete it (or may be use the target directory so that it will be anyway removed). since both underlying, but external tycho and equinox launcher plug-ins > used by our carbon-feature-plugin require this file as an input. > > So IMO, the only improvement that we can introduce here is supporting > templated-dynamic-creation of the file at carbon-feature-plugin level > using the standard carbon kernel version values available in the > distribution pom. > > Thanks, > Dilan. > > *Dilan U. Ariyaratne* > Senior Software Engineer > WSO2 Inc. <http://wso2.com/> > Mobile: +94766405580 <%2B94766405580> > lean . enterprise . middleware > > > On Mon, Jan 23, 2017 at 7:33 AM, Kishanthan Thangarajah < > kishant...@wso2.com> wrote: > >> >> >> On Fri, Jan 20, 2017 at 5:57 PM, Afkham Azeez <az...@wso2.com> wrote: >> >>> I would suggest totally getting rid of it. >>> >> >> To maintain backward compatibility of the plugin, we need to have the >> file based supported. But from next major release of the plugin, we can >> remove the usage of this file and use the pom based approach only. >> >> Thanks, >> >>> >>> On Fri, Jan 20, 2017 at 5:24 PM, KasunG Gajasinghe <kas...@wso2.com> >>> wrote: >>> >>>> >>>> +1. carbon.product file hasn't really been used by the products. So, >>>> +1 to make it optional. >>>> >>>> On Fri, Jan 20, 2017 at 3:06 PM, Dilan Udara Ariyaratne < >>>> dil...@wso2.com> wrote: >>>> >>>>> Hi Folks, >>>>> >>>>> In the process of building C5, we currently require carbon.product for >>>>> the following goals. >>>>> [1] publish-product >>>>> [2] generate-runtime >>>>> >>>>> This file maintains current version of the carbon kernel to be >>>>> utilized by "carbon-feature-plugin" in the build process. >>>>> Keeping this value in carbon.product prevents the kernel from been >>>>> auto-released as it requires manual intervention to bump >>>>> version values as necessary during the release process. >>>>> >>>>> In order to solve this issue, we are currently in the process of >>>>> improving Carbon-Feature-Plugin to dynamically create this file during >>>>> build time using >>>>> a template where the necessary version value information is read from >>>>> corresponding distribution pom file. >>>>> >>>>> In order to support backward compatibility, we will still maintain the >>>>> original approach of keeping a carbon.product file somewhere appropriate >>>>> in the distribution folder and read it accordingly when >>>>> tag is present in the pom file. >>>>> >>>>> In the meantime, as the way to go forward, we will introduce the >>>>> following. >>>>> >>>>> Carbon-Feature-Plugin will be updated to read version and other >>>>> optional values that were originally persisted in the file, from the pom >>>>> itself. >>>>> After reading these values, plugin will dynamically create the >>>>> carbon.product which will then be taken into reference by underlying >>>>> eclipse.tycho plugin as in the usual way of execution. >>>>> >>>>> WDYT ? >>>>> >>>>> Thank You. >>>>> >>>>> *Dilan U. Ariyaratne* >>>>> Senior Software Engineer >>>>> WSO2 Inc. <http://wso2.com/> >>>>> Mobile: +94766405580 <%2B94766405580> >>>>> lean . enterprise . middleware >>>>> >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Kasun Gajasinghe*Associate Te
Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template
On Fri, Jan 20, 2017 at 5:57 PM, Afkham Azeez <az...@wso2.com> wrote: > I would suggest totally getting rid of it. > To maintain backward compatibility of the plugin, we need to have the file based supported. But from next major release of the plugin, we can remove the usage of this file and use the pom based approach only. Thanks, > > On Fri, Jan 20, 2017 at 5:24 PM, KasunG Gajasinghe <kas...@wso2.com> > wrote: > >> >> +1. carbon.product file hasn't really been used by the products. So, +1 >> to make it optional. >> >> On Fri, Jan 20, 2017 at 3:06 PM, Dilan Udara Ariyaratne <dil...@wso2.com> >> wrote: >> >>> Hi Folks, >>> >>> In the process of building C5, we currently require carbon.product for >>> the following goals. >>> [1] publish-product >>> [2] generate-runtime >>> >>> This file maintains current version of the carbon kernel to be utilized >>> by "carbon-feature-plugin" in the build process. >>> Keeping this value in carbon.product prevents the kernel from been >>> auto-released as it requires manual intervention to bump >>> version values as necessary during the release process. >>> >>> In order to solve this issue, we are currently in the process of >>> improving Carbon-Feature-Plugin to dynamically create this file during >>> build time using >>> a template where the necessary version value information is read from >>> corresponding distribution pom file. >>> >>> In order to support backward compatibility, we will still maintain the >>> original approach of keeping a carbon.product file somewhere appropriate >>> in the distribution folder and read it accordingly when >>> tag is present in the pom file. >>> >>> In the meantime, as the way to go forward, we will introduce the >>> following. >>> >>> Carbon-Feature-Plugin will be updated to read version and other optional >>> values that were originally persisted in the file, from the pom itself. >>> After reading these values, plugin will dynamically create the >>> carbon.product which will then be taken into reference by underlying >>> eclipse.tycho plugin as in the usual way of execution. >>> >>> WDYT ? >>> >>> Thank You. >>> >>> *Dilan U. Ariyaratne* >>> Senior Software Engineer >>> WSO2 Inc. <http://wso2.com/> >>> Mobile: +94766405580 <%2B94766405580> >>> lean . enterprise . middleware >>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc. >> email: kasung AT spamfree wso2.com >> linked-in: http://lk.linkedin.com/in/gajasinghe >> blog: http://kasunbg.org >> phone: +1 650-745-4499 <+1%20650-745-4499>, 77 678 0813 >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Afkham Azeez* > Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **az...@wso2.com* <az...@wso2.com> > * cell: +94 77 3320919 <+94%2077%20332%200919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 <+94%2077%20342%206635> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Identity Server] Creating a server configuration Identity.yaml vs component wise yaml files and Reading the server configurations
On Thu, Jan 19, 2017 at 2:03 PM, Johann Nallathamby <joh...@wso2.com> wrote: > Hi Danushka, > > Did you see [1]? The thread talks about a single config file for the most > commonly changed config files. However the thread doesn't seem to have a > conclusion. > > @Kernel Team, > Is this something we have completed implementing? If so can you share some > latest details of how we should be using it? > Yes, please check the doc - https://github.com/wso2/ carbon-kernel/blob/master/docs/DeveloperTools/UpdatingConfigurations.md > > @Danushka, > In any case one mistake we made in C4 based IS is reading and parsing the > identity.xml from a single component - identity.core. We must not make the > same mistake again. Each component must pass its own configuration in the > yaml file using snakeyaml and build its own configuration model. This will > achieve less coupling among bundles. Of course you can have utilities in > [2] if needed to pass identity.yaml but nothing specific to a specific > feature. > > So I think to summarize, the configuration file is specific to the product > and a single file for the whole server, but parsing the file is the > responsibility of each component. This doesn't apply for more complex > configurations such as claim-config.yaml, user-store-config.yaml, etc. > > [1] [Architecture] Configuration files in C5 > [2] https://github.com/wso2/carbon-identity-commons/tree/mas > ter/components/org.wso2.carbon.identity.common/src/main/java > /org/wso2/carbon/identity/common/util > > Regards, > Johann. > > On Thu, Jan 19, 2017 at 1:46 PM, Danushka Fernando <danush...@wso2.com> > wrote: > >> Hi All >> We are currently working on setting challenge questions feature for IS >> 6.0.0-M1. We need some configurations specific to security questions / >> account recovery section. In C4 based products it was in identity.xml which >> is the server configuration. In C5 code we dont have created a such file. >> We have several user management related configs which are deployed >> separately in C4 as well. But when we are moving towards C5, what should be >> the way of creating these configs. Is it component wise or server wise? >> >> Any ideas are appreciated. >> >> Thanks & Regards >> Danushka Fernando >> Senior Software Engineer >> WSO2 inc. http://wso2.com/ >> Mobile : +94716332729 <+94%2071%20633%202729> >> > > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Technical Lead & Product Lead of WSO2 Identity Server > Governance Technologies Team > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+9476950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 <+94%2077%20342%206635> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] [C5] MSF4J Interceptors need to be configurable.
t goes to next Interceptor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks & Regards, >>>>>>>> Ishara Cooray >>>>>>>> Senior Software Engineer >>>>>>>> Mobile : +9477 262 9512 <077%20262%209512> >>>>>>>> WSO2, Inc. | http://wso2.com/ >>>>>>>> Lean . Enterprise . Middleware >>>>>>>> >>>>>>>> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez <az...@wso2.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> How about supporting JAXRS filters? >>>>>>>>> >>>>>>>>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne < >>>>>>>>> thusit...@wso2.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Ishara, >>>>>>>>>> >>>>>>>>>> As you have mentioned, with the current architecture we can't set >>>>>>>>>> the specific interceptor for a particular service but rather to all >>>>>>>>>> services in the registry. And also if there are multiple >>>>>>>>>> interceptors and >>>>>>>>>> one interceptor returns false from its' preCaall then the invocation >>>>>>>>>> chain >>>>>>>>>> will not continue further. >>>>>>>>>> >>>>>>>>>> IMHO we have few options >>>>>>>>>> >>>>>>>>>>- We can implement a way to register specific interceptors to >>>>>>>>>>specific services >>>>>>>>>>- We can support JAX-RS Filters >>>>>>>>>>- We can provide a way to skip some interceptors for specific >>>>>>>>>>services >>>>>>>>>> >>>>>>>>>> @Azeez WDYT? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Thusitha >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray <isha...@wso2.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> HI, >>>>>>>>>>> >>>>>>>>>>> We are using MSF4J interceptor for securing REST APIs in API >>>>>>>>>>> Manager. [1] As for now Interceptor registration happens at the >>>>>>>>>>> class level >>>>>>>>>>> @Component annotation as below. >>>>>>>>>>> >>>>>>>>>>> @Component( >>>>>>>>>>> name = "org.wso2.carbon.apimgt.rest.a >>>>>>>>>>> pi.common.interceptors.OAUTH2SecurityInterceptor", >>>>>>>>>>> service = Interceptor.class, >>>>>>>>>>> immediate = true >>>>>>>>>>> ) >>>>>>>>>>> The limitations here are >>>>>>>>>>> >>>>>>>>>>>1. it is not possible to have more than one interceptor that >>>>>>>>>>>will dynamically pick when an api call is received(Because the >>>>>>>>>>> order >>>>>>>>>>>matters and we are not certain which interceptor will take into >>>>>>>>>>> effect ). >>>>>>>>>>>2. We cannot explicitly configure to use Custom interceptors >>>>>>>>>>>because of the above[1] reason. >>>>>>>>>>> >>>>>>>>>>> Do we have any plans for these limitations? >>>>>>>>>>> >>>>>>>>>>> Thanks & Regards, >>>>>>>>>>> Ishara Cooray >>>>>>>>>>> Senior Software Engineer >>>>>>>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>>>>>>>> WSO2, Inc. | http://wso2.com/ >>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ___ >>>>>>>>>>> Dev mailing list >>>>>>>>>>> d...@wso2.org >>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Thusitha Dayaratne >>>>>>>>>> Software Engineer >>>>>>>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>>>>>>> >>>>>>>>>> Mobile +94712756809 <071%20275%206809> >>>>>>>>>> Blog alokayasoya.blogspot.com >>>>>>>>>> Abouthttp://about.me/thusithathilina >>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ___ >>>>>>>>>> Architecture mailing list >>>>>>>>>> Architecture@wso2.org >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Afkham Azeez* >>>>>>>>> Senior Director, Platform Architecture; WSO2, Inc.; >>>>>>>>> http://wso2.com >>>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>>> * <http://www.apache.org/>* >>>>>>>>> *email: **az...@wso2.com* <az...@wso2.com> >>>>>>>>> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: * >>>>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>>>>> <http://twitter.com/afkham_azeez> >>>>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>>>> >>>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Afkham Azeez* >>>>>>> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com >>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>> * <http://www.apache.org/>* >>>>>>> *email: **az...@wso2.com* <az...@wso2.com> >>>>>>> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: * >>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>>>> <http://twitter.com/afkham_azeez> >>>>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>> >>>>>>> *Lean . Enterprise . Middleware* >>>>>>> >>>>>> >>>>>> >>>>> >>>>> ___ >>>>> Dev mailing list >>>>> d...@wso2.org >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Sagara Gunathunga >>>> >>>> Associate Director / Architect; WSO2, Inc.; http://wso2.com >>>> V.P Apache Web Services;http://ws.apache.org/ >>>> Linkedin; http://www.linkedin.com/in/ssagara >>>> Blog ; http://ssagara.blogspot.com >>>> >>>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 <+94%2071%20306%208779> >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Associate Director / Architect; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services;http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 <+94%2077%20342%206635> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WebSocket support for MSF4J
e ability to do server pushes using >>>> the WebSocket Sessions and to do so we need to have the reference of >>>> Netty's Channel Handler Context. >>>> >>>> In MSF4J >>>> >>>>- Need a separate Registry to register WebSocket EndPoints since >>>>WebSoocket EndPoints are different from MicroServices >>>>- Message Processor gets the correct EndPoint from the registry and >>>>dispatch the message >>>> >>>> >>>> Any thoughts? >>>> >>>> Thanks & Best Regards, >>>> Irunika >>>> *Irunika Weeraratne* >>>> *Software Engineer | WSO2, Inc. <http://wso2.com/>* >>>> *Email : irun...@wso2.com <irun...@wso2.com>* >>>> *LinkedIn : https://lk.linkedin.com/in/irunika >>>> <https://lk.linkedin.com/in/irunika>* >>>> *Mobile : +94712403314 <+94%2071%20240%203314>* >>>> *Lean . Enterprise . Middleware* >>>> >>>> >>> >> > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Kernel changes/improvements needed for IS release
On Thu, Oct 20, 2016 at 10:12 AM, Jayanga Dissanayake <jaya...@wso2.com> wrote: > Hi Niranjan, > > You are correct, by the time a feature is developed, it is not defined, to > which profiles this feature goes into. And the profiles are defined at the > product level. (as per the C4) > > Above (directory structure) is the proposed structure for the new > distributions. We have not yet finalized with the P2 related stuff and the > process on how to build a pack with above-mentioned requirements is still > in discussion. > For the provisioning story, we can look at the OBR - OSGi Bundle Repository (felix has an implementation for this) as we don't see an absolute requirement for P2 now. We do not need a separate repo to host bundles/features. The maven repo itself can be used as the OBR repo. And we only need this at product build time. Will update the thread once we finalize the process. > > Thanks, > Jayanga. > > *Jayanga Dissanayake* > Associate Technical Lead > WSO2 Inc. - http://wso2.com/ > lean . enterprise . middleware > email: jaya...@wso2.com > mobile: +94772207259 > <http://wso2.com/signature> > > On Wed, Oct 19, 2016 at 4:29 PM, Niranjan Karunanandham <niran...@wso2.com > > wrote: > >> Hi Jayanga, >> >> On Wed, Oct 19, 2016 at 3:42 PM, Jayanga Dissanayake <jaya...@wso2.com> >> wrote: >> >>> Yesterday we had a meeting to discuss about the IS distribution and >>> followings are the changes/improvements that are needed to be provided by >>> the kernel. >>> >>>- Server “conf” and “deployment” directory locations should be >>>configurable >>>- Refer [1] potential directory structure for IS. It will have top >>>level directories for each profile in which we put profile specific, >>> config >>>files and startup scrips. There will be one place "osgi/plugins" in which >>>we place all the bundles needed for a product. And we use profiles to >>>control which bundles get loaded for each profile >>> >>> The location where the configuration files need to be copied is defined >> at the p2.inf of the feature. Therefore if the top level folder say "mb" is >> considered as the profile in which case the at the time of creating a >> feature is the profile defined, i.e., each feature will define in which >> profile it will belong to or the current p2 profile generation is followed >> and via assembly plugin (bin.xml), this change is done? >> >>> >>>- Deployer should be able to deploy the artifacts in the configured >>>directory this is the default behaviour. And it should be able to >>> specify a >>>set of artifacts via parameters and get only those artifacts deployed >>>- Check how long does it take to load/initialize the Log4j and >>>evaluate the possibility of utilizing JUL or something better. >>>- There is a requirement to support remote configuration repo and >>>handle dynamic configuration changes. The plan is to use ETCD repository. >>>- Analyse kernel memory dump and see what are the unwanted >>>things/classes that are loaded and try to optimize. >>>- Run Java Dependency Analyser (jdeps) tool and identify the minimal >>>dependency set that is needed for the kernel/product to run >>> >>> >>> [1] wso2-is >>> |--nel >>>|--conf >>>|-- >>> |--mb >>> |--conf >>> |-- >>> |--analytics >>> |--tooling >>> |--osgi >>>|--plugins >>> >>> >>> Thanks, >>> *Jayanga Dissanayake* >>> Associate Technical Lead >>> WSO2 Inc. - http://wso2.com/ >>> lean . enterprise . middleware >>> email: jaya...@wso2.com >>> mobile: +94772207259 >>> <http://wso2.com/signature> >>> >> >> Regards, >> Nira >> >> -- >> >> >> *Niranjan Karunanandham* >> Associate Technical Lead - WSO2 Inc. >> WSO2 Inc.: http://www.wso2.com >> >> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] OpenID Connect Based SSO valve for WSO2 AS 6.0.0
defined in the authentication response, then it should be used in the >authentication request. Otherwise a auto generated value should be used. > > >- As the value of ‘state’ is used for the validation of authentication >response, it should be stored in the valve. We have decided to to store it >in a HashMap. But it can be improved in future. > > This should be an extension point. We can use a map (as the default in-memory state storage) but we need to provide this as an extension point so that users can plug in their own extended way to store the state value. Can you also explain about how the user authenticated parameters (claims, attributes, userinfo attributes. etc) are passed along the valve to the endpoint? Thanks, Kishanthan. > >- > > > For reference: > >- > >Specification of OpenID Connect ><http://openid.net/specs/openid-connect-core-1_0.html> > > > > > > > > > > On Tue, Aug 30, 2016 at 12:50 PM, Kishanthan Thangarajah < > kishant...@wso2.com> wrote: > >> Ok, so making this a general agent with well defined API's could solve >> this. We can then write a valve or a filter using this library. We will go >> ahead with the valve now and later we can include a filter also. >> >> @Abilashini, shall we first come up with the API's for this? The >> requirement here is valve or filter should be able consume APIs exposed >> from this agent library for doing OpenID Connect based requests creation, >> response validations. etc. >> >> On Mon, Aug 29, 2016 at 3:15 PM, Johann Nallathamby <joh...@wso2.com> >> wrote: >> >>> >>> >>> On Mon, Aug 29, 2016 at 2:55 PM, Kishanthan Thangarajah < >>> kishant...@wso2.com> wrote: >>> >>>> Hi Johann, >>>> >>>> Few questions I need to clarify. >>>> >>>> So the requirement here is, the app developer wants to inject some >>>> custom attributes, which cannot be predefined using the wo2as-web.xml >>>> config file, to the request before the *authentication flow* is >>>> started by the valve right? >>>> >>>> How a can filter (or any entity) identify different type of requests >>>> and inject attributes based on the type of the request? Do we have some >>>> examples (reference) on these dynamic attributes? >>>> >>> >>> That is basically the web application logic. Users can implement the >>> filter in whatever way they want to identify the requests and set the >>> scopes, claims, acr values etc. to make the request much more dynamic. In >>> real world use cases we can't have static configurations for these, even if >>> we have it at per SP level. >>> >>> >>>> >>>> On Sun, Aug 28, 2016 at 1:41 PM, Johann Nallathamby <joh...@wso2.com> >>>> wrote: >>>> >>>>> Hi Abilashini, >>>>> >>>>> The valve approach might not be able to cater all webapp developer >>>>> requirements. Especially there are certain parameters in the OIDC request >>>>> which can be dynamic, changes from request to request, e.g. claims, >>>>> scopes, >>>>> etc. During the meeting we had we decided to provide them as configuration >>>>> parameters in as_web.xml. However thinking again I don't think a webapp >>>>> developer is always able to limit himself to a constant set of values for >>>>> these parameters. >>>>> >>>>> So there must be a way for the webapp developer to provide these >>>>> values dynamically to our OIDC implementation. If we take the valve >>>>> approach it may be bit hard because webapp develop can't inject any >>>>> attributes before our valve gets executed. To do that you need to place a >>>>> valve in front of our valve by editing the catalina-server.xml. >>>>> >>>>> However if we take a filter, webapp developer can write and place a >>>>> filter before our filter gets executed and inject certain attribute values >>>>> he wants to the request. These attributes are well defined attributes in >>>>> our implementation that can give us the dynamic values the developer >>>>> wants. >>>>> >>>>> So I am not totally discarding the valve approach. I think the best >>>>> way to do it would be to implement it as a standalone agent library which >>>>> can be invoked from a valve or filter or anyt
Re: [Architecture] Multiple profile support for C5 based products.
On Wed, Oct 12, 2016 at 7:00 PM, Nuwan Dias <nuw...@wso2.com> wrote: > > > On Wed, Oct 12, 2016 at 6:55 PM, Kishanthan Thangarajah < > kishant...@wso2.com> wrote: > >> >> >> On Wed, Oct 12, 2016 at 6:29 PM, Nuwan Dias <nuw...@wso2.com> wrote: >> >>> Do we really need multi-profile support (at an osgi level) on C5? What >>> if we have separate dedicated runtimes per profile? Which means that we >>> have a gateway runtime, store runtime, etc. within the same distribution? >>> Each will run on its own port, maybe using offsets by default (no need to >>> worry about that if each profile is a container). >>> >> >> This is the similar thing we are trying propose. The "profiles" concept >> is C5 is actually runtime we are talking about. It is not only about osgi >> bundles, but everything a runtime needs to start on its own. >> >> For example, api-manager store runtime needs set of bundles, >> configuration files and store UI component written using uuf/jaggery. The >> tool will create this runtime by reading the descriptor file and launch the >> instance as a separate JVM. >> > > But why would we need a tool to do that? What if we build the product > itself in that manner. > It's not only about API-Manager product but the same requirement is needed for IoT product (and IS may also have the requirement when running the user/admin portal separately) that require multiple runtimes. So isn't it better to provide a common way to do this? > Ex: Store will have all its bundles, config files, etc in a single > directory. And it'll have its own startup script (.sh). Same will be for > the publisher and other runtimes. It will result in a certain amount of > duplicate jars in those directories (carbon kernel), but that isn't much of > a problem isn't it? Do you see any other problems in doing that? > The duplication will be high here IMO based on the passed experience. The pack size will increase due to this. > >> Additionally if we have option of docker compose given, then it will >> launch a docker instance with the store runtime. >> >> >>> Also if we have profiles, do we also have a global profile which runs >>> all components in one? >>> >> >> No, with the above model, there will not be a single profile (or global >> profile) which has all the runtime components in it and we have to move >> away from single product running all the components together in the same >> JVM. Each runtime will be started as different processes/JVM (can be >> OSGi-java process and just another java process). >> >> If a runtime needs a non-OSGi java process (say for example you want to >> start activemq as part of the product), then you can also do that using >> this proposed approach. >> >> >> >>> I doubt we'll be able to achieve the target of 1 to 2 sec startup time >>> if we do that. >>> >>> Thanks, >>> NuwanD. >>> >>> On Wed, Oct 12, 2016 at 3:40 PM, Muhammed Shariq <sha...@wso2.com> >>> wrote: >>> >>>> With regards to the discussion on improving some of the limitations in >>>> the our current product profiles support [1], we had a discussion to >>>> rethink how we can improve the support for running different profiles in >>>> C5. >>>> >>>> Participants - Lakmal, Azeez, Imesh, Kishanthan, Jayanga, Chandana, >>>> Rohan >>>> >>>> *Limitations with the current approach* >>>> >>>> - We only consider the bundles.info and load the necessary bundles, >>>> however there might be certain configs and deployment artifacts that's not >>>> required >>>> - Some functionalities that aren't required for certain profiles are >>>> enabled (e.g. transports) >>>> - Distribution size is not optimal for container native architecture >>>> >>>> *Suggestion for profile support in C5* >>>> >>>> Considering the above limitation, we decided on building a profile >>>> specific distribution from the base distribution. The base distribution >>>> will pack all artifacts and also profile specific descriptors >>>> >>>> If there are any configs specific to a profile, those configs can be >>>> changed using the deployment.properties file. The base distribution will >>>> have deployment.properties file specific to the profiles, that way we don't >>>> have to duplicate any config files. >>>> >>>>
Re: [Architecture] Storing configs in database for C5
ops by eliminating complicated puppet config >>>>>>>>> templates that need to constantly maintained with new releases. >>>>>>>>> >>>>>>>>> 5. Since configs are in a central DB its easy to manage them since >>>>>>>>> all nodes will read from the same table. >>>>>>>>> >>>>>>>>> 6. Configs can be backed up by simply backing up the table >>>>>>>>> >>>>>>>>> >>>>>>>>> Doing this makes sense for certain use cases of API Manger, I'm >>>>>>>>> sure there maybe similar benefits for other products as well. It may >>>>>>>>> not >>>>>>>>> make sense for all configs but at least for some that govern feature >>>>>>>>> functionality its great to have. WDYT? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Regards, >>>>>>>>> Uvindra >>>>>>>>> >>>>>>>>> Mobile: 33962 >>>>>>>>> >>>>>>>>> ___ >>>>>>>>> Architecture mailing list >>>>>>>>> Architecture@wso2.org >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sajith Kariyawasam >>>>>>>> *Associate Tech Lead* >>>>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com/>* >>>>>>>> *Committer and PMC member, Apache Stratos * >>>>>>>> *AMIE (SL)* >>>>>>>> *Mobile: 0772269575 <0772269575>* >>>>>>>> >>>>>>>> ___ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Uvindra >>>>>>> >>>>>>> Mobile: 33962 >>>>>>> >>>>>>> ___ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Lakmali Baminiwatta >>>>>> Associate Technical Lead >>>>>> WSO2, Inc.: http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> mobile: +94 71 2335936 >>>>>> blog : lakmali.com >>>>>> >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>> email : nuw...@wso2.com >>>>> Phone : +94 777 775 729 >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Lakmali Baminiwatta >>>> Associate Technical Lead >>>> WSO2, Inc.: http://wso2.com >>>> lean.enterprise.middleware >>>> mobile: +94 71 2335936 >>>> blog : lakmali.com >>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : nuw...@wso2.com >>> Phone : +94 777 775 729 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Srinath Perera, Ph.D. >>http://people.apache.org/~hemapani/ >>http://srinathsview.blogspot.com/ >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] User-Core Unique User Id Implementation
Hi Akalanka, On Tue, Oct 11, 2016 at 4:58 PM, Akalanka Pagoda Arachchi < darsha...@wso2.com> wrote: > Hi All, > > We're implementing the Unique User Id concept in C5 User Core. This > evolved as a requirement with the introduction of the Domain model to the > User Core. > > The user domain model is as follows. > >- Users are available in multiple domains. >- Each domain can contain more than one IdentityStoreConnector. >- Each connector will have a set of user attributes. >- A user is an object created by combining all the attributes in >IdentityStoreConnectors for a domain. >- Each user attribute from an IdentityStoreConnector maps to a >specific claim. > > When resolving a user, there should be a mapping to identify the same user > between different connectors. For this purpose we're introducing a Unique > User Id concept. The idea behind Unique User Id is as follows. > > >- A Unique User Id will be unique across the User-Core no matter the >domain the user in. > > Are you saying that this ID will be unique across all the domains? > >- This unique Id will be maintained in a database table. >- The table will contain mapping for the Unique Id to each connectors' >individual user Id. >GlobalUniqueId | ConnectorUserId | ConnectorId > > In here, can you also clearly explain the relationship between GlobalUniqueId, ConnectorUserId and/or UniqueUserId? Because, this will cause confusion as they all refer as an identifier for the user. And how they will be used in resolving a user? > When retrieving all the Claims for a User, following sequence will be > followed. > >- Get user from primary attribute > > Need to explain what is a primary attribute here with an example? Also how primary attribute is configured at connector level? > >- Get unique user Id from mapping table for that user >- Find the connector which has the required attribute >- Get connector specific user Id for the required connector from the >mapping table >- Retrieve attribute value from that connector. > > A simplified sequence diagram for this flow is as below. > In the below sequence diagram, I think we have missed how the UniqueUserId is retrieved before calling the UserBuilder.setUniqueUserID. Is that correct? > > > > > *Sequence Diagram for getClaim* > > One important note on this implementation is that as of the current design > UserCore will not be responsible for populating the unique user Id mapping > table. How and where this should be populated is still an open discussion. > Any suggestions are welcome. > How many DB/connector level calls that this will have in doing a typical user retrieval with above suggestion? What will be the performance impact? Thanks, Kishanthan. > > Thanks, > Akalanka. > > > > -- > *Darshana Akalanka Pagoda Arachchi,* > *Senior Software Engineer, WSO2* > *+94777118016 <%2B94777118016>* > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] How can we improve our profiles story?
at 5:27 PM, Muhammed Shariq <sha...@wso2.com> >>>> wrote: >>>> >>>>> Hi folks, >>>>> >>>>> I had a chat with Sameera and Jayanga on how we can improve support >>>>> for managing configurations for a particular profile. >>>>> >>>>> We were discussing the possibility of extending the ConfigResolver [1] >>>>> concept to manage profile specific configurations. With ConfigResolver, we >>>>> have the ability to override certain configurations using the >>>>> deployment.properties file, this way we only need modify a single file to >>>>> override configurations scattered in different files. >>>>> >>>>> We are looking into the possibility of using the ConfigResolver >>>>> approach to handle configs related to a specific profile as well. The idea >>>>> is to have a profile specific deployment.properties file where we can >>>>> specify the configs related to that particular profile. This way we can >>>>> avoid duplicating the same config file and parameteriz values using the >>>>> properties file. >>>>> >>>>> If we build a pack specific to a particular profile, this might create >>>>> complication for the simplest scenario where a user wants to simply >>>>> extract >>>>> the distribution and try it out. With profile specific distributions, >>>>> users >>>>> will have to deal with multiple distributions (configuring offsets etc) >>>>> even to try out a product which is cumbersome. >>>>> >>>>> So I feel, having a per profile properties is a feasible mechanism to >>>>> define profile specify configs. Shall we go ahead with this approach? >>>>> >>>>> Any concerns, thoughts? >>>>> >>>>> [1] - [Architecture] [C5] Adding deployment.properties file to >>>>> override configurations in components >>>>> [2] - [C5] Less configuration elements with meaningful defaults >>>>> >>>>> On Mon, Oct 3, 2016 at 5:11 PM, Sameera Jayasoma <same...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> We can categorize all the files which need to be handled by profiles >>>>>> into three groups. >>>>>> >>>>>> >>>>>> *1) OSGi repository * >>>>>> >>>>>>- *Location:* repository/components >>>>>>- *Description:* Contains all the OSGi bundles, dropins artifacts >>>>>>and other required files. This repository is already organized into >>>>>>multiple profiles(if any). >>>>>> >>>>>> >>>>>> *2) Config repository* >>>>>> >>>>>>- *Location:* repository/conf >>>>>>- *Description: Contains configuration files of the products. We >>>>>>need to figure out a way handle profile specific configuration files.* >>>>>> >>>>>> >>>>>> *3) Artifact repository* >>>>>> >>>>>>- *Location*: repository/deployment >>>>>>- *Description*: Contains deployment artifacts of the product. We >>>>>>need to figure out a way to handle profile specific deployment >>>>>> artifacts. >>>>>> >>>>>> >>>>>> Shariq from the platform team will work on this. >>>>>> >>>>>> Thanks, >>>>>> Sameera. >>>>>> >>>>>> On Fri, Sep 23, 2016 at 3:18 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Sep 23, 2016 at 2:38 PM, Srinath Perera <srin...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I think this happen with ESB NIO transport and Servelt transport >>>>>>>> for webapps. ( Nuwan, is there other examples?). >>>>>>>> >>>>>>> >>>>>>> In the regsitry.xml, we configure the indexers and handlers. These >>>>>>> again are only required in certain profiles. There are also some >>>>>>> configs in >>>>>>> the api-manager
Re: [Architecture] [AppM] Best practice to re-use domain objects in the gateway handlers
ntext. But then again consume a lot of memory when there is a high >>>>>>> load. >>>>>>> >>>>>>> One solution to above issue to create a new thin domain object with >>>>>>> only the necessary fields for the gateway. >>>>>>> >>>>>>> Thoughts please ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Best Regards* >>>>>>> >>>>>>> *Rushmin Fernando* >>>>>>> *Technical Lead* >>>>>>> >>>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>>>>> >>>>>>> mobile : +94772891266 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Isuru Udana* >>>>>> Technical Lead >>>>>> WSO2 Inc.; http://wso2.com >>>>>> email: isu...@wso2.com cell: +94 77 3791887 >>>>>> blog: http://mytecheye.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Best Regards* >>>>> >>>>> *Rushmin Fernando* >>>>> *Technical Lead* >>>>> >>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>>> >>>>> mobile : +94772891266 >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Best Regards* >>>> >>>> *Rushmin Fernando* >>>> *Technical Lead* >>>> >>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>> >>>> mobile : +94772891266 >>>> >>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >> >> -- >> *Imesh Gunaratne* >> Software Architect >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: https://medium.com/@imesh TW: @imesh >> lean. enterprise. middleware >> >> >> > > > -- > *Best Regards* > > *Rushmin Fernando* > *Technical Lead* > > WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware > > mobile : +94772891266 > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] How can we improve our profiles story?
Current issue is that all bundles and artifacts (conf files, webapps) are common to the server which are shared among all the profiles. We don't have a way to delete and modify them when starting up a profile. One other option is we could pack everything (profile specific artifacts) in the base distribution and provide a build script (ant) which create profile specific runtime a. We will check for the other alternatives along with this PoC and see. On Thu, Sep 22, 2016 at 12:27 PM, Afkham Azeez <az...@wso2.com <javascript:_e(%7B%7D,'cvml','az...@wso2.com');>> wrote: > We proposed an idea to build a pack based on a profile. That will contain > only the essential stuff. So rather than starting up a runtime and then > loading a profile, you build a pack that contains the bare minimum stuff > required. Perhaps we can have a descriptor which describes what non-OSGi > stuff are required for a profile and we can combine that with the OSGi > bundles.info to figure out exactly what is needed. Can someone in the > kernel team do a quick PoC? > > On Thu, Sep 22, 2016 at 11:26 AM, Srinath Perera <srin...@wso2.com > <javascript:_e(%7B%7D,'cvml','srin...@wso2.com');>> wrote: > >> Smaeera, are these things we can fix? >> >> --Srinath >> >> On Thu, Sep 22, 2016 at 11:23 AM, Nuwan Dias <nuw...@wso2.com >> <javascript:_e(%7B%7D,'cvml','nuw...@wso2.com');>> wrote: >> >>> Hi, >>> >>> This is to raise some concerns over the current server profiles. >>> Although we are able to control the bundles which are loaded to the runtime >>> based on the -Dprofile parameter, we still lack the ability of removing >>> files and modifying configuration files when the server starts on a >>> profile. And this is forcing us to start unnecessary bundles at startup. >>> Let me explain... >>> >>> API Manager has both webapps and a gateway in its distribution. The >>> synapse bundles are only required in the Gateway profiles. However since >>> the axis2.xml file of API Manager defines the http transport senders and >>> receivers based on the Synapse passthrough senders and receivers, the axis2 >>> engine will try to load the synapse classes on startup. Ideally if we were >>> able to modify the axis2.xml on the Publisher, Store and Key Manager >>> profiles and replace the passthrough senders and receivers with our >>> standard http senders and receivers, we could avoid loading the synapse >>> bundles on the Publisher, Store and Key Manager. >>> >>> The same problem occurs for registry indexers and handlers. Since the >>> registry indexers and handlers are configured on the registry.xml, even >>> though these are only required in the publisher and store profiles, these >>> bundles will be activated and running even on the Gateway, Key Manager and >>> Traffic Manager. So unless we modify the registry.xml on those nodes >>> manually, we can't stop those bundles from running. >>> >>> Another problem we're facing is the inability to remove webapps. Since >>> all webapps in the repository/deployment/server/webapps and >>> repository/deployment/server/jaggeryapps are deployed into the runtime, >>> unless we remove these webapps manually there is no other way to stop them >>> from being deployed in unrelated profiles. >>> >>> I heard there is a discussion to bind a profile to a container. Which >>> would solve these problems. However it still won't help the "non-container" >>> deployments. Are there ways to overcome the above mentioned limitations and >>> enhance the efficiency of our profiles? >>> >>> Thanks, >>> NuwanD. >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : nuw...@wso2.com >>> <javascript:_e(%7B%7D,'cvml','nuw...@wso2.com');> >>> Phone : +94 777 775 729 >>> >> >> >> >> -- >> >> Srinath Perera, Ph.D. >>http://people.apache.org/~hemapani/ >>http://srinathsview.blogspot.com/ >> > > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **az...@wso2.com* <javascript:_e(%7B%7D,'cvml','az...@wso2.com');> > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.c
Re: [Architecture] OpenID Connect Based SSO valve for WSO2 AS 6.0.0
Ok, so making this a general agent with well defined API's could solve this. We can then write a valve or a filter using this library. We will go ahead with the valve now and later we can include a filter also. @Abilashini, shall we first come up with the API's for this? The requirement here is valve or filter should be able consume APIs exposed from this agent library for doing OpenID Connect based requests creation, response validations. etc. On Mon, Aug 29, 2016 at 3:15 PM, Johann Nallathamby <joh...@wso2.com> wrote: > > > On Mon, Aug 29, 2016 at 2:55 PM, Kishanthan Thangarajah < > kishant...@wso2.com> wrote: > >> Hi Johann, >> >> Few questions I need to clarify. >> >> So the requirement here is, the app developer wants to inject some custom >> attributes, which cannot be predefined using the wo2as-web.xml config file, >> to the request before the *authentication flow* is started by the valve >> right? >> >> How a can filter (or any entity) identify different type of requests and >> inject attributes based on the type of the request? Do we have some >> examples (reference) on these dynamic attributes? >> > > That is basically the web application logic. Users can implement the > filter in whatever way they want to identify the requests and set the > scopes, claims, acr values etc. to make the request much more dynamic. In > real world use cases we can't have static configurations for these, even if > we have it at per SP level. > > >> >> On Sun, Aug 28, 2016 at 1:41 PM, Johann Nallathamby <joh...@wso2.com> >> wrote: >> >>> Hi Abilashini, >>> >>> The valve approach might not be able to cater all webapp developer >>> requirements. Especially there are certain parameters in the OIDC request >>> which can be dynamic, changes from request to request, e.g. claims, scopes, >>> etc. During the meeting we had we decided to provide them as configuration >>> parameters in as_web.xml. However thinking again I don't think a webapp >>> developer is always able to limit himself to a constant set of values for >>> these parameters. >>> >>> So there must be a way for the webapp developer to provide these values >>> dynamically to our OIDC implementation. If we take the valve approach it >>> may be bit hard because webapp develop can't inject any attributes before >>> our valve gets executed. To do that you need to place a valve in front of >>> our valve by editing the catalina-server.xml. >>> >>> However if we take a filter, webapp developer can write and place a >>> filter before our filter gets executed and inject certain attribute values >>> he wants to the request. These attributes are well defined attributes in >>> our implementation that can give us the dynamic values the developer wants. >>> >>> So I am not totally discarding the valve approach. I think the best way >>> to do it would be to implement it as a standalone agent library which can >>> be invoked from a valve or filter or anything else which will be more >>> future proof. >>> >>> Also remember the implementation for state parameter should use an >>> extension point to store context information until the authorization >>> request is sent to IDP and response is received. The default implementation >>> could be a in-memory map, but users may extend this to implement using >>> session, database, distributed maps, etc. >>> >>> On Thu, Aug 25, 2016 at 6:28 PM, Abilashini Thiyagarajah < >>> abilash...@wso2.com> wrote: >>> >>>> Hi, >>>> >>>> >>>> OpenID Connect is an authentication layer on top of OAuth 2.0 protocol >>>> which is becoming more popular to be used. The idea of this project is to >>>> implement a valve for WSO2 AS which supports OpenID Connect based Single >>>> Sign On (SSO). The valve will be implemented as a global level Tomcat >>>> Valve. >>>> >>>> Following diagram explains the flow of Authorization code which is a >>>> type of openID connect. >>>> >>>> >>>> Parameters of the flow, >>>> >>>> Authentication Request >>>> >>>> scope, response_type, client_id, redirect_uri, state >>>> >>>> Authentication Response >>>> >>>> code, state >>>> >>>> If failed : error, state >>>> >>>> Token Request >>>> >>>> grand_type, code, redirect_uri, client_i
Re: [Architecture] OpenID Connect Based SSO valve for WSO2 AS 6.0.0
; Functionalities of the Valve : >> >> >>1. >> >>Send Authentication Request. >>2. >> >>Validate the Authentication Response. >>3. >> >>Send Token Request. >>4. >> >>Validate the Token Response. >>5. >> >>Send UserInfo Request of scope/claim by sending the access token. >>6. >> >>Should support SLO >>7. >> >>Generic error handling should be done by the valve. >>8. >> >>When a user initiates a request, it should check whether the web app >>is configured as OpenID Connect SSO then check whether it has an >>authenticated session then it should do the redirection. >>9. >> >>It should keep the user informations of each request as a model >>object in the request session. >> >> > Let's also think about storing this information as a request attribute. > These days usage of webapp sessions are no more a given. People sometimes > prefer using other forms of storage due to some problems with sessions. > > Regards, > Johann. > > >> >> -- >> T. Abilashini >> Intern >> Software Engineering >> WSO2 Inc. http://wso2.com/ >> Phone +94 719248432 >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Technical Lead & Product Lead of WSO2 Identity Server > Governance Technologies Team > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+9476950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] AS 6.0.0 HTTP Monitoring (analytics-http)
Hi Kalpa, Can you send a status update on $subject and what are the pending tasks? Let's target the next milestone release of AS with this feature. Thanks, -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Data Bridge Agent Publisher for C5 products
t; https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Sinthuja Rajendran* >> Associate Technical Lead >> WSO2, Inc.:http://wso2.com >> >> Blog: http://sinthu-rajan.blogspot.com/ >> Mobile: +94774273955 >> >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Isuru Perera > Associate Technical Lead | WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > about.me/chrishantha > Contact: +IsuruPereraWSO2 <https://www.google.com/+IsuruPereraWSO2/about> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Carbon Context API
On Thu, May 19, 2016 at 11:49 AM, Isuru Haththotuwa <isu...@wso2.com> wrote:
> HI Kicha,
>
> On Fri, May 6, 2016 at 3:58 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> CarbonContext is the API to store and retrieve data which are thread
>> local.
>>
>>- There are two API classes, CarbonContext [1]
>>and PrivilegedCarbonContext [2].
>>- CarbonContext (CC) is the ReadOnly API, which is basically the user
>>level API and PrivilegedCarbonContext will be the ReadWrite API which is
>>secured using java security permission.
>>- From CarbonContext, a user can get the "Principal", which is the
>>currently logged-in users' JAAS principal for authorization.
>>
>> If so, can someone deploy a bundle that can access the currently logged
> user's Principal information and use it to authorize an action with that?
> If its possible, it is a security problem.
>
The properties of the principal is used with evaluating wether an action
can be authorized or not for the currently logged in user. It will not have
any sensitive information rather it would have the logged in user name and
the users' attributes. Also on the other hand, any component should first
be trusted (signed) and then it should get invoked in the currently
executing thread for it to access CarbonContext. Even if the component has
access to the principal, it will only gain access to some attributes that
does not have any sensitive information. This is same behaviour as what we
had in C4 based CarbonContext access. Tomcat also provide a similar API -
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/connector/Request.html#getUserPrincipal()
>- CarbonContext API also has the ability to set and get properties,
>which is to support setting any properties that can be later used within a
>thread execution flow.
>
>
>> *Retrieving Tenant Information*
>> In C5 based products, a server instance will be dedicated to a tenant.
>> From the CarbonContext API, a user can get the tenant name to which the
>> server is bound to. There will not be any setter API for setting tenant
>> name as we will read the tenant name from either carbon.yml configuration
>> file [3] or from a system/environment variable.
>>
> What is the order we are enforcing here? IMHO it should be first the
> environment variable and then the carbon.yaml.
>
Currently when we build the configuration, we search for first env and then
system properties only when the specific property configured to use place
holder like ${PROP_KEY}. So there is no order here. If a value is there,
then it is used. Or of a place holder is given, then we search for env and
then system properties.
>> *Usage*
>> CarbonContext carbonContext = CarbonContext.getCurrentContext();
>> String tenant = carbonContext.getTenant();
>> Principal principal = carbonContext.getUserPrincipal();
>> Object propertyValue = carbonContext.getProperty("PROPERTY_KEY");
>>
>> PrivilegedCarbonContext privilegedCarbonContext =
>> PrivilegedCarbonContext.getCurrentContext();
>> privilegedCarbonContext.setUserPrincipal(userPrincipal);
>> privilegedCarbonContext.setProperty("PROPERTY_KEY", propertyValue);
>>
>> Thanks,
>> Kishanthan.
>> [1]
>> https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/context/CarbonContext.java
>> [2]
>> https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/context/PrivilegedCarbonContext.java
>> [3]
>> https://github.com/wso2/carbon-kernel/blob/master/features/org.wso2.carbon.kernel.feature/resources/conf/carbon.yml#L20
>>
>> --
>> *Kishanthan Thangarajah*
>> Associate Technical Lead,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635
>> Blog - *http://kishanthan.wordpress.com
>> <http://kishanthan.wordpress.com>*
>> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>>
>> _______
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Carbon Context API
Sorry for the delayed response.
On Fri, May 6, 2016 at 7:53 PM, Manuranga Perera <m...@wso2.com> wrote:
> Object propertyValue = carbonContext.getProperty("PROPERTY_KEY");
>
>
> What kind of values will be available, can you please give an example?
>
This API is added to pass contextual information along the thread. There
are some existing use-cases with C4. For example, we previously used axis2
API's (eg - Message Context) for this purpose to store and retrieve
properties (mostly objects such as current request) that are used later in
the execution flow.
> On Fri, May 6, 2016 at 6:28 AM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> CarbonContext is the API to store and retrieve data which are thread
>> local.
>>
>>- There are two API classes, CarbonContext [1]
>>and PrivilegedCarbonContext [2].
>>- CarbonContext (CC) is the ReadOnly API, which is basically the user
>>level API and PrivilegedCarbonContext will be the ReadWrite API which is
>>secured using java security permission.
>>- From CarbonContext, a user can get the "Principal", which is the
>>currently logged-in users' JAAS principal for authorization.
>>- CarbonContext API also has the ability to set and get properties,
>>which is to support setting any properties that can be later used within a
>>thread execution flow.
>>
>>
>> *Retrieving Tenant Information*
>> In C5 based products, a server instance will be dedicated to a tenant.
>> From the CarbonContext API, a user can get the tenant name to which the
>> server is bound to. There will not be any setter API for setting tenant
>> name as we will read the tenant name from either carbon.yml configuration
>> file [3] or from a system/environment variable.
>>
>> *Usage*
>> CarbonContext carbonContext = CarbonContext.getCurrentContext();
>> String tenant = carbonContext.getTenant();
>> Principal principal = carbonContext.getUserPrincipal();
>> Object propertyValue = carbonContext.getProperty("PROPERTY_KEY");
>>
>> PrivilegedCarbonContext privilegedCarbonContext =
>> PrivilegedCarbonContext.getCurrentContext();
>> privilegedCarbonContext.setUserPrincipal(userPrincipal);
>> privilegedCarbonContext.setProperty("PROPERTY_KEY", propertyValue);
>>
>> Thanks,
>> Kishanthan.
>> [1]
>> https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/context/CarbonContext.java
>> [2]
>> https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/context/PrivilegedCarbonContext.java
>> [3]
>> https://github.com/wso2/carbon-kernel/blob/master/features/org.wso2.carbon.kernel.feature/resources/conf/carbon.yml#L20
>>
>> --
>> *Kishanthan Thangarajah*
>> Associate Technical Lead,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635
>> Blog - *http://kishanthan.wordpress.com
>> <http://kishanthan.wordpress.com>*
>> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>>
>> _______
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [C5] Carbon Context API
CarbonContext is the API to store and retrieve data which are thread local.
- There are two API classes, CarbonContext [1]
and PrivilegedCarbonContext [2].
- CarbonContext (CC) is the ReadOnly API, which is basically the user
level API and PrivilegedCarbonContext will be the ReadWrite API which is
secured using java security permission.
- From CarbonContext, a user can get the "Principal", which is the
currently logged-in users' JAAS principal for authorization.
- CarbonContext API also has the ability to set and get properties,
which is to support setting any properties that can be later used within a
thread execution flow.
*Retrieving Tenant Information*
In C5 based products, a server instance will be dedicated to a tenant. From
the CarbonContext API, a user can get the tenant name to which the server
is bound to. There will not be any setter API for setting tenant name as we
will read the tenant name from either carbon.yml configuration file [3] or
from a system/environment variable.
*Usage*
CarbonContext carbonContext = CarbonContext.getCurrentContext();
String tenant = carbonContext.getTenant();
Principal principal = carbonContext.getUserPrincipal();
Object propertyValue = carbonContext.getProperty("PROPERTY_KEY");
PrivilegedCarbonContext privilegedCarbonContext =
PrivilegedCarbonContext.getCurrentContext();
privilegedCarbonContext.setUserPrincipal(userPrincipal);
privilegedCarbonContext.setProperty("PROPERTY_KEY", propertyValue);
Thanks,
Kishanthan.
[1]
https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/context/CarbonContext.java
[2]
https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/context/PrivilegedCarbonContext.java
[3]
https://github.com/wso2/carbon-kernel/blob/master/features/org.wso2.carbon.kernel.feature/resources/conf/carbon.yml#L20
--
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Handling product versions in microservices
Sorry wrong thread. Please ignore the above.
On Thu, May 5, 2016 at 2:30 PM, Kishanthan Thangarajah <kishant...@wso2.com>
wrote:
> Another thing is, should we also work on exposing admin services on one
> listener (probably over https) and other user api's on different listener?
> May be we need to bring in some changes to MSF4J core to support this via
> OSGi level service properties and listener id's.
>
> On Thu, May 5, 2016 at 2:17 PM, Afkham Azeez <az...@wso2.com> wrote:
>
>> In what cases would you require to maintain multiple versions of a
>> microservice in a product? Or is this related to different versions of the
>> same product? If it is the second case, it is the responsibility of the
>> gateway to route to the correct instances and there is no need to maintain
>> version information on the product runtime side.
>>
>> On Thu, May 5, 2016 at 2:12 PM, Sameera Jayasoma <same...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, May 5, 2016 at 12:42 PM, Hasitha Aravinda <hasi...@wso2.com>
>>> wrote:
>>>
>>>> Some more questions
>>>>
>>>> On Thu, May 5, 2016 at 12:30 PM, Sameera Jayasoma <same...@wso2.com>
>>>> wrote:
>>>>
>>>>> I believe its wrong to use the product version to version your micro
>>>>> services.
>>>>>
>>>>> You need to have different version for your microservices. e.g.
>>>>> starting from 1.0.0. If you don't change any of your microservices you
>>>>> shouldn't be changing these versions.
>>>>>
>>>>
>>>> According to Rest API guideline, it should be product version. isn't
>>>> it ?
>>>>
>>>
>>> We cannot change API versions for each and every product release. You
>>> should change the API version only if you have introduced a change. We are
>>> following the same approach to version export packages from bundles.
>>>
>>>
>>>>
>>>> Let's say we are using version from 1.0.0.
>>>> If we are going to do a modification
>>>>
>>>> to a microservice ( let's say foo 1.0) and new version is foo 1.1 Do
>>>> we need to maintain both versions to provide backward compatibility ? If so
>>>> we have to maintain two microservices: Foo 1.0 and Foo 1.1, because version
>>>> is a part of the path in microservice.
>>>>
>>>
>>> I am not sure whether need to maintain the previous versions of micro
>>> services. Thats something we need to discuss. Also it adds complexity.
>>>
>>> If you have introduced any additions to your micro services, then you
>>> can bump up the minor version number. If you've introduced incompatible
>>> changes, then you have bump up the major version number.
>>>
>>>
>>>
>>>>
>>>> eg:
>>>> @Path("
>>>> /bps/bpmn/v
>>>> 1
>>>> .0/
>>>> foo
>>>> ")
>>>> ,
>>>> @Path("
>>>> /bps/bpmn/v
>>>> 1
>>>> .
>>>> 1
>>>> /
>>>> foo
>>>> ")
>>>>
>>>> Thanks,
>>>> Hasitha.
>>>>
>>>>
>>>>> On Thu, May 5, 2016 at 11:02 AM, Himasha Guruge <himas...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> We have refactored our REST APIs by implementing Microservice
>>>>>> interface. According to the new REST guideline , we need to maintain the
>>>>>> URL format like below. For example,
>>>>>>
>>>>>> http://localhost:/bps/bpmn/v4.0/repository/deployments
>>>>>>
>>>>>> How are we going to maintain the product version updates with
>>>>>> microservices? If we are to maintain the product version with a
>>>>>> parameter
>>>>>> been set from a config file, how can we achieve this?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Himasha Guruge
>>>>>> *Software Engineer*
>>>>>> WS*O2* *Inc.*
>>>>>> Mobile: +94 777459299
>>>>>> himas...@wso2.com
>>>>>>
>>>>>> ___
>>>>>> Architecture mailing list
>>&g
Re: [Architecture] Ports to use for Admin Services in C5
Another thing is, should we also work on exposing admin services on one listener (probably over https) and other user api's on different listener? May be we need to bring in some changes to MSF4J core to support this via OSGi level service properties and listener id's. On Thu, May 5, 2016 at 7:39 AM, Afkham Azeez <az...@wso2.com> wrote: > Will you run admin stuff & user stuff on the same instances? At least > shouldn't our recommendation be that admin & user stuff have to be > separate, as a best practice? > > On Wed, May 4, 2016 at 9:12 PM, Hasitha Aravinda <hasi...@wso2.com> wrote: > >> Hi Manu, >> >> In my point of view, we have to decide it based on what API does and who >> are the actual users involve. >> >> In BPS, we have two sets of users: workflow participants and admin >> user/devOps of the BPS. Based on these users we can categorized BPS APIs >> into two sets. >> >>- Admin APIs : There are few APIs like artifact deployer API, >>accessed only by administrators of the server or devOps. >> >> >>- User APIs : BPMN Rest API and HumanTask API are user APIs, because >>these APIs only accessed by participants of processes and user tasks. But >>we can argue some of the operations are admin operations, but those are >>business admin operations. These resources/operations need to >>be authorized using an ACL, based on current user and his role in workflow >>or user-task. >> >> For example in HumanTask [1], we have several roles i.e. Business >> Administrator, Potential Owners, Excluded Owners, Stakeholders etc. Based >> on current user and his role in defined task, user are authorized to >> perform an operation. >> >> IMO having clear separations between User API and Admin API may >> important when securing these APIs separately. >> >> [1] - >> http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cs-01.html#_Toc261430341 >> >> Thanks, >> Hasitha. >> >> On Wed, May 4, 2016 at 7:55 PM, Manuranga Perera <m...@wso2.com> wrote: >> >>> How do we define an admin vs non-admin API? >>> Is getting list of users different from getting the list of processes? >>> >>> A customer written UI may have to call both. We can argue that some >>> things are 100% admin eg: shutdown server. But to me this seems like an >>> arbitrary decision. >>> >>> >>> On Wed, May 4, 2016 at 12:14 AM, Hasitha Aravinda <hasi...@wso2.com> >>> wrote: >>> >>>> Another thing, we need to consider exposing different ports for user >>>> APIs and Admin APIs to have a clear separation. In C4 all user and admin >>>> APIs exposed in 9443 and 9763. AFAIK this is not supported in current MSF4J >>>> OSGi version. >>>> >>>> Thanks, >>>> Hasitha. >>>> >>>> On Wed, May 4, 2016 at 9:26 AM, Nandika Jayawardana <nand...@wso2.com> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> In all the carbon platform versions up to now, we used 9443, and 9763 >>>>> ports for admin services for all server products. Are we going to use the >>>>> same ports for C5. >>>>> >>>>> Regards >>>>> Nandika >>>>> >>>>> -- >>>>> Nandika Jayawardana >>>>> WSO2 Inc ; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> -- >>>> Hasitha Aravinda, >>>> Senior Software Engineer, >>>> WSO2 Inc. >>>> Email: hasi...@wso2.com >>>> Mobile : +94 718 210 200 >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : m...@wso2.com >>> >> >> >> >> -- >> -- >> Hasitha Aravinda, >> Senior Software Engineer, >> WSO2 Inc. >&
Re: [Architecture] Handling product versions in microservices
364456 >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> -- >>> Hasitha Aravinda, >>> Senior Software Engineer, >>> WSO2 Inc. >>> Email: hasi...@wso2.com >>> Mobile : +94 718 210 200 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sameera Jayasoma, >> Software Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: same...@wso2.com >> blog: http://blog.sameera.org >> twitter: https://twitter.com/sameerajayasoma >> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >> Mobile: 0094776364456 >> >> Lean . Enterprise . Middleware >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **az...@wso2.com* <az...@wso2.com> > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] C5 User Core - Realm Service API
Can you provide a code sample on how the user authorization is done (the flow) based on the above explanation? On Tue, May 3, 2016 at 2:31 PM, Jayanga Kaushalya <jayan...@wso2.com> wrote: > Hi Kishanthan, > > Respective store ids are available through the respective beans. For > example User bean has the identity store id and the credential store id. To > call an API which requires a store id, you needs to have the respective > bean first. For example by authenticating an user via calling authenticate > method will return an User bean with it's identity store id and the > credential store id. Or otherwise by calling getUser(username) method you > can get the User bean. Most of the operations which requires an store id > can be directly called from the bean it self. For example isUserAuthorized > can be called like User.isAuthorized(Permission). > > Thanks! > > *Jayanga Kaushalya* > Software Engineer > Mobile: +94777860160 > WSO2 Inc. | http://wso2.com > lean.enterprise.middleware > > On Tue, May 3, 2016 at 11:56 AM, Kishanthan Thangarajah < > kishant...@wso2.com> wrote: > >> Most of the API methods we could see that we need to pass the >> identityStoreId like below. >> >> public boolean isUserAuthorized(String userId, Permission permission, >> String identityStoreId) >> >> How do we identify this store-id before calling? >> >> On Sat, Apr 30, 2016 at 10:12 PM, Jayanga Kaushalya <jayan...@wso2.com> >> wrote: >> >>> Hi Darshana, >>> >>> Yes, those links are correct. We have changed the package name from >>> org.wso2.carbon.security to org.wso2.carbon.security.caas since that is the >>> name we are going to use in future. >>> >>> Thanks! >>> >>> *Jayanga Kaushalya* >>> Software Engineer >>> Mobile: +94777860160 >>> WSO2 Inc. | http://wso2.com >>> lean.enterprise.middleware >>> >>> On Sat, Apr 30, 2016 at 6:49 PM, Darshana Gunawardana <darsh...@wso2.com >>> > wrote: >>> >>>> I assume these should be the correct links. @Jayanga please correct me >>>> if I'm wrong. >>>> >>>> [1] >>>> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/service/RealmService.java >>>> [2] >>>> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/common/CarbonRealmServiceImpl.java >>>> [3] >>>> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/store/AuthorizationStore.java >>>> [4] >>>> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/store/CredentialStore.java >>>> [5] >>>> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/store/IdentityStore.java >>>> >>>> Regards, >>>> Darshana >>>> >>>> On Fri, Apr 29, 2016 at 11:36 PM, Kishanthan Thangarajah < >>>> kishant...@wso2.com> wrote: >>>> >>>>> Can you send the correct git-hub links to these API's? Provided links >>>>> are either wrong or packages/modules have been renamed. >>>>> >>>>> On Fri, Apr 29, 2016 at 6:35 PM, Jayanga Kaushalya <jayan...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> User core related authentication and authorization operations can be >>>>>> accessed through RealmService. Bellow diagram explains the brief outlook >>>>>> of >>>>>> the Realm service and respective stores. >>>>>> >>>>>> >>>>>> *RealmService* >>>>>> >>>>>> Realm service is the User Core API which is exposed to external >>>>>> users. Each store can be accessed through the realm service. API is >>>>>> available in [1] >>>>>> >>>>>> *CarbonRealmServiceImpl* >>>>>> >>>>>> Implementation of the realm service. API is available in [2] >>>>>> >>>>>> *IdentityStore* >>>>>> >>>>>> Identity store c
Re: [Architecture] C5 User Core - Realm Service API
Most of the API methods we could see that we need to pass the identityStoreId like below. public boolean isUserAuthorized(String userId, Permission permission, String identityStoreId) How do we identify this store-id before calling? On Sat, Apr 30, 2016 at 10:12 PM, Jayanga Kaushalya <jayan...@wso2.com> wrote: > Hi Darshana, > > Yes, those links are correct. We have changed the package name from > org.wso2.carbon.security to org.wso2.carbon.security.caas since that is the > name we are going to use in future. > > Thanks! > > *Jayanga Kaushalya* > Software Engineer > Mobile: +94777860160 > WSO2 Inc. | http://wso2.com > lean.enterprise.middleware > > On Sat, Apr 30, 2016 at 6:49 PM, Darshana Gunawardana <darsh...@wso2.com> > wrote: > >> I assume these should be the correct links. @Jayanga please correct me if >> I'm wrong. >> >> [1] >> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/service/RealmService.java >> [2] >> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/common/CarbonRealmServiceImpl.java >> [3] >> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/store/AuthorizationStore.java >> [4] >> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/store/CredentialStore.java >> [5] >> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security.caas/src/main/java/org/wso2/carbon/security/caas/user/core/store/IdentityStore.java >> >> Regards, >> Darshana >> >> On Fri, Apr 29, 2016 at 11:36 PM, Kishanthan Thangarajah < >> kishant...@wso2.com> wrote: >> >>> Can you send the correct git-hub links to these API's? Provided links >>> are either wrong or packages/modules have been renamed. >>> >>> On Fri, Apr 29, 2016 at 6:35 PM, Jayanga Kaushalya <jayan...@wso2.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> User core related authentication and authorization operations can be >>>> accessed through RealmService. Bellow diagram explains the brief outlook of >>>> the Realm service and respective stores. >>>> >>>> >>>> *RealmService* >>>> >>>> Realm service is the User Core API which is exposed to external users. >>>> Each store can be accessed through the realm service. API is available in >>>> [1] >>>> >>>> *CarbonRealmServiceImpl* >>>> >>>> Implementation of the realm service. API is available in [2] >>>> >>>> *IdentityStore* >>>> >>>> Identity store contains all identity management related read only >>>> operations. All CRUD operations related to identity management will be >>>> available through extended version of the user core and which will be >>>> available through carbon identity repository. >>>> API details are available in the [5]. >>>> >>>> *CredentialStore* >>>> >>>> Credential store contains all credential management related read only >>>> operations. All CRUD operations related to the credential management will >>>> be available through extended version of the user core and which will be >>>> available through carbon identity repository. >>>> API details are available in the [4] >>>> >>>> *AuthorizationStore* >>>> >>>> All authorization related CRUD operations will be available through the >>>> authorization store. API details are available in the [3] >>>> >>>> [1] >>>> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security/src/main/java/org/wso2/carbon/security/user/core/service/RealmService.java >>>> >>>> [2] >>>> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security/src/main/java/org/wso2/carbon/security/user/core/common/CarbonRealmServiceImpl.java >>>> [3] >>>> https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security/src/main/java/org/wso2/carbon/security/user/core/store/AuthorizationStore.java >>>> [4] >>>> https://github.com/wso2/carbon-security/blob/master/components/o
Re: [Architecture] C5 User Core - Realm Service API
Can you send the correct git-hub links to these API's? Provided links are either wrong or packages/modules have been renamed. On Fri, Apr 29, 2016 at 6:35 PM, Jayanga Kaushalya <jayan...@wso2.com> wrote: > Hi all, > > User core related authentication and authorization operations can be > accessed through RealmService. Bellow diagram explains the brief outlook of > the Realm service and respective stores. > > > *RealmService* > > Realm service is the User Core API which is exposed to external users. > Each store can be accessed through the realm service. API is available in > [1] > > *CarbonRealmServiceImpl* > > Implementation of the realm service. API is available in [2] > > *IdentityStore* > > Identity store contains all identity management related read only > operations. All CRUD operations related to identity management will be > available through extended version of the user core and which will be > available through carbon identity repository. > API details are available in the [5]. > > *CredentialStore* > > Credential store contains all credential management related read only > operations. All CRUD operations related to the credential management will > be available through extended version of the user core and which will be > available through carbon identity repository. > API details are available in the [4] > > *AuthorizationStore* > > All authorization related CRUD operations will be available through the > authorization store. API details are available in the [3] > > [1] > https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security/src/main/java/org/wso2/carbon/security/user/core/service/RealmService.java > > [2] > https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security/src/main/java/org/wso2/carbon/security/user/core/common/CarbonRealmServiceImpl.java > [3] > https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security/src/main/java/org/wso2/carbon/security/user/core/store/AuthorizationStore.java > [4] > https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security/src/main/java/org/wso2/carbon/security/user/core/store/CredentialStore.java > [5] > https://github.com/wso2/carbon-security/blob/master/components/org.wso2.carbon.security/src/main/java/org/wso2/carbon/security/user/core/store/IdentityStore.java > > *Jayanga Kaushalya* > Software Engineer > Mobile: +94777860160 > WSO2 Inc. | http://wso2.com > lean.enterprise.middleware > > _______ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] The location of the wso2as-web.xml within Application Server structure
+1, let's use the META-INF directory for our config files. On Thu, Apr 28, 2016 at 4:48 PM, Chiranga Alwis <chira...@wso2.com> wrote: > Hi, > the all new wso2as-web.xml web application descriptor for WSO2 Application > Server 6.0.0 is a configurations file reminiscent to Apache Tomcat's > context.xml file. > > The primary reasons behind the introduction of this file are as follows: > 1. Separate out the WSO2 specific configurations from those related to > Tomcat in order to improve the usability. > 2. Separate out the configurations which are configurable at web > application level from those which are configurable at server level. > 3. Provide the facility to set configurations globally, effective for all > web applications and also to override those configurations at web > application level for the desired web application(s). > > This file can be currently added to the /WEB-INF of a web > application. > But in my belief, since wso2as-web.xml file acts as a configurations file > specific to WSO2 Application Server or more precisely an application server > specific configurations file, this file should move > to /META-INF folder. > > I found an accurate description about this from the book 'Professional > Java for Web Applications' by Nicholas S. Williams. This description comes > under the 'Directory structure and WAR Files' section of chapter 1 of the > book. It is as follows: > > "You probably also noticed the presence of two different META-INF > directories. This can be a source of confusion for some developers, but if > you remember the simple classpath rules, you can easily differentiate the > two. Like JAR file META-INF directories, the root-level /META-INF directory > contains the application manifest file. It can also contain resources for > specific web containers or application servers. For example, Apache Tomcat > (which you’ll learn about in Chapter 2) looks for and uses a context.xml > file in this directory to help customize how the application is deployed in > Tomcat. None of these files are part of the Java EE specification, and the > supported files can vary from one application server or > web container to the next." (from page 14-15) > > Any suggestions and ideas with regards to the location of this file are > highly appreciated. > > -- > Chiranga Alwis, > Software Engineering Intern, > +94 77 5930497 > +94 77 6368208 > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Must Inject CarbonServerInfo when writing OSGi Test Cases
Can we also add this to the kernel osgi test framework documentation as a best practice guideline? On Thu, Apr 7, 2016 at 6:21 PM, Aruna Karunarathna <ar...@wso2.com> wrote: > Hi Devs, > > When writing OSGi Test Cases, Please Inject the CarbonServerInfo service > [1]. Otherwise the container wont start properly and the test cases will > fail. > > After injecting the service it will guarantee that the server will fully > start, before running the test cases. e.g. [2] > > > [1]. > https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/utils/CarbonServerInfo.java > [2]. > https://github.com/wso2/carbon-kernel/blob/master/tests/osgi-tests/src/test/java/org/wso2/carbon/osgi/startupresolver/SampleStartupOrderResolverOSGiTest.java#L71 > > Regards, > Aruna > -- > > *Aruna Sujith Karunarathna * > WSO2, Inc | lean. enterprise. middleware. > #20, Palm Grove, Colombo 03, Sri Lanka > Mobile: +94 71 9040362 | Work: +94 112145345 > Email: ar...@wso2.com | Web: www.wso2.com > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] WSO2 Application Server 6.0.0-M1 Released !
Thanks Lahiru for testing this release. Did you also get a chance to test the HTTP stat publishing valve? On Tue, Apr 5, 2016 at 10:45 PM, Lahiru Manohara <lahir...@wso2.com> wrote: > Hi All, > > We tested WSO2 Application Server 6.0.0 M1 with AppCloud and now we can > deploy java run-time's application with WSO2 AS. > > Thanks! > > On Tue, Apr 5, 2016 at 9:39 PM, Kalpa Welivitigoda <kal...@wso2.com> > wrote: > >> Hi all, >> >> Please use https://github.com/wso2/product-as/releases/tag/v6.0.0-m1 to >> download the distribution. >> >> On Tue, Apr 5, 2016 at 7:14 PM, Kalpa Welivitigoda <kal...@wso2.com> >> wrote: >> >>> WSO2 Application Server 6.0.0-M1 Released >>> >>> Welcome to WSO2 Application Server, the successor of WSO2 Carbon based >>> Application Server. WSO2 Application Server 6.0.0 is a complete revamp and >>> is based on vanilla Apache Tomcat. WSO2 provides a number of features by >>> means of extensions to Tomcat to add/enhance the functionality. It provides >>> first class support for generic web applications and JAX-RS/JAX-WS web >>> applications. The performance of the server and individual application can >>> be monitored by integrating WSO2 Application Server with WSO2 Data >>> Analytics Server. >>> >>> WSO2 Application Server is an open source project and it is available >>> under the Apache Software License (v2.0) >>> <http://www.apache.org/licenses/LICENSE-2.0.html> . >>> Key Features >>> >>>- HTTP Statistics Monitoring >>>- Webapp Classloading Runtimes >>> >>> Fixed Issues >>> >>>- https://wso2.org/jira/browse/WSAS-2202?filter=13011 >>> >>> Known Issues >>> >>>- https://wso2.org/jira/browse/WSAS-2212?filter=13012 >>> >>> Reporting Issues >>> >>> Issues, documentation errors and feature requests regarding WSO2 >>> Application Server can be reported through the public issue tracking >>> system. https://wso2.org/jira/browse/WSAS. >>> Contact us WSO2 Application Server developers can be contacted via the >>> Development <d...@wso2.org> and Architecture <architecture@wso2.org> >>> mailing lists. >>> Alternatively, questions can also be raised in the stackoverflow forum : >>> http://stackoverflow.com/questions/tagged/wso2 >>> >>> Thank you for your interest in WSO2 Application Server. >>> >>> * -The WSO2 Application Server Development Team - * >>> >> >> >> >> -- >> Best Regards, >> >> Kalpa Welivitigoda >> Software Engineer, WSO2 Inc. http://wso2.com >> Email: kal...@wso2.com >> Mobile: +94776509215 >> >> ___ >> Dev mailing list >> d...@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Best regards, > > *Lahiru Manohara* > *Software Engineer* > Mobile: +94716561576 > WSO2 Inc. | http://wso2.com > lean.enterprise.middleware > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Application Server 6.0.0 - Architecture
All the valves and extensions are part of tomcat. We can show the runtime engine separately and we do not need to show the request flow on the same diagram but focus only on the core components and where it fits in the architecture. The valve names should be correctly named. What we have is SAML based SSO valve whereas tomcat itself also provides an SSO valve. On Fri, Apr 1, 2016 at 10:21 AM, Kalpa Welivitigoda <kal...@wso2.com> wrote: > Hi Manuri, > > > > On Fri, Apr 1, 2016 at 9:23 AM, Manuri Amaya Perera <manu...@wso2.com> > wrote: > >> Hi Kalpa, >> >> In the request flow diagram, why are tomcat valves orthogonal to the >> other valves? >> >> > "Tomcat Valves" represents that the above are Tomcat valves, the boarder > of "Tomcat valves" makes it confusing, I agree. Thanks for the feedback. > > Also "Apache Tomcat" needs to be renamed to something like "Apache Tomcat > engine" or "servlet/JSP engine", because Tomcat valves are also a part of > Tomcat Server. > > >> Thanks. >> Manuri >> >> On Thu, Mar 31, 2016 at 3:53 PM, Kalpa Welivitigoda <kal...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> WSO2 Application Server 6.0.0 is based on Apache Tomcat 8.0. To >>> add/enhance functionality, we have developed WSO2 modules and are packaged >>> as libraries in the application server distribution. I have listed the >>> modules we have in place with a brief description. >>> >>> >>>- HTTP statistics monitoring >>> >>> This feature is to monitor HTTP traffic to the server. We have >>> HttpStatValve, a Tomcat valve to collect and publish data to DAS. The >>> monitoring aspect of the feature, the dashboard is being developed with >>> WSO2 Dashboard Server (The earlier dashboard was a jaggery app). >>> >>>- Webapp loader >>> >>> This feature allows the users to configure different classloading >>> environments for webapps. This can be configured globally (for all the >>> webapps) or per webapp. We had this feature in carbon based AS as well. It >>> is ported to AS 6.0 with some improvements. By default we have enabled CXF >>> runtime in the server, meaning a user can deploy a JAX-RS webapp without >>> any additional configuration in the server. >>> >>>- appserver-utils >>> >>> This module contains utils and configuration context that are to be used >>> by other modules and for future extensions. >>> >>> We have implemented a test framework based on testng for integration >>> tests. We also have introduced new descriptor files, a server descriptor >>> named wso2as.xml and a webapp deployment descriptor named wso2as-web.xml. >>> These descriptors have the configuration related to the above features. >>> wso2as-web.xml can be used inside webapps as well in case the >>> configurations for that particular webapp (for example class loading) needs >>> to be differed that from the server wide. >>> >>> With the above in mind we have come up with the component diagram and >>> request flow diagram attached herewith. Any comments/suggestions? >>> >>> >>> >>> >>> -- >>> Best Regards, >>> >>> Kalpa Welivitigoda >>> Software Engineer, WSO2 Inc. http://wso2.com >>> Email: kal...@wso2.com >>> Mobile: +94776509215 >>> >>> _______ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *Manuri Amaya Perera* >> >> *Software Engineer* >> >> *WSO2 Inc.* >> >> *Blog: http://manuriamayaperera.blogspot.com >> <http://manuriamayaperera.blogspot.com>* >> > > > > -- > Best Regards, > > Kalpa Welivitigoda > Software Engineer, WSO2 Inc. http://wso2.com > Email: kal...@wso2.com > Mobile: +94776509215 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] What's "id" in carbon.yml, which is in Carbon 5 conf directory
On Thu, Mar 31, 2016 at 9:58 AM, Selvaratnam Uthaiyashankar <
shan...@wso2.com> wrote:
>
>
> On Fri, Mar 25, 2016 at 11:56 AM, Aruna Karunarathna <ar...@wso2.com>
> wrote:
>
>> On Thu, Mar 24, 2016 at 7:28 PM, Isuru Perera <isu...@wso2.com> wrote:
>>
>>> So, when deploying multiple products, this "id" should be changed and
>>> each server must specify a unique id, right? (Otherwise how can we uniquely
>>> identify a server?)
>>>
>>> How can I access this "id" from my component. Is there an API?
>>>
>>
>> Yes you should give a unique id value, if you want to identify the server
>> uniquely.
>>
>
> How does this work in an autoscaled environment? Autoscalar should update
> this file with unique value?
>
We don't have to edit the file here. By default, we will have a place
holder for this property in the carbon.yml file - id: ${server.key}.
The value for this can be set either via a system property or an
environment variable. So when a new instance is spawned, we don't have to
edit the file but we have to set the relevant value (sys or env property)
for this.
> Do we have documentation about this "id"?
>
No, we are working on documenting these config files.
>
>
>
>
>> There is no such API, to get it directly, What you can do is, acquire
>> the CarbonRuntime OSGi service,
>> and get the ServerConfiguration which contain this information.
>>
>> [1].
>> https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/CarbonRuntime.java#L40
>>
>>>
>>> On Thu, Mar 24, 2016 at 6:30 PM, Aruna Karunarathna <ar...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Mar 24, 2016 at 6:23 PM, Isuru Perera <isu...@wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> $subject?
>>>>>
>>>>> What are the reasons for adding it? Can I use that to identify a
>>>>> carbon server uniquely?
>>>>>
>>>>> For example, in Carbon Metrics, I want to use some value to identify a
>>>>> server (The source of metrics). So, I have used a configuration named
>>>>> source and I use hostname as the default value. Can we use this "id" for
>>>>> that?
>>>>>
>>>>
>>>> AFAIK, you can use that value to uniquely identify a server. That's
>>>> the idea behind that property.
>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> Isuru Perera
>>>>> Associate Technical Lead | WSO2, Inc. | http://wso2.com/
>>>>> Lean . Enterprise . Middleware
>>>>>
>>>>> about.me/chrishantha
>>>>> Contact: +IsuruPereraWSO2
>>>>> <https://www.google.com/+IsuruPereraWSO2/about>
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Aruna Sujith Karunarathna *
>>>> WSO2, Inc | lean. enterprise. middleware.
>>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>>> Mobile: +94 71 9040362 | Work: +94 112145345
>>>> Email: ar...@wso2.com | Web: www.wso2.com
>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Isuru Perera
>>> Associate Technical Lead | WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> about.me/chrishantha
>>> Contact: +IsuruPereraWSO2
>>> <https://www.google.com/+IsuruPereraWSO2/about>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Aruna Sujith Karunarathna *
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 71 9040362 | Work: +94 112145345
>> Email: ar...@wso2.com | Web: www.wso2.com
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> S.Uthaiyashankar
> VP Engineering
> WSO2 Inc.
> http://wso2.com/ - "lean . enterprise . middleware"
>
> Phone: +94 714897591
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Maven project naming convention
On Fri, Mar 25, 2016 at 12:44 AM, Manuranga Perera <m...@wso2.com> wrote:
> Our current naming convention [1] looks like:
> org.wso2.carbon
> org.wso2.carbon.core
>
> But I believe it should be like (and maven recommended [2]):
> org.wso2.carbon
> kernel
>
> (I see the second patten in some C5 based code [3]. So not sure which one
> is the convention.)
>
The reason we use the first is that, we are following equinox bundle naming
convention (and most of the apache OSGi related projects uses the same
convention) and also to avoid any duplication of bundle names with OSGi
runtime.
> One issue with the second approach is, there is a risk of Bundle-Name not
> being unique since we currently use "${project.artifactId}" as the
> Bundle-Name. But we can easily use something like "
> ${project.artifactId}.${project.groupId}" instead.
>
Yes, this is an option but I don't see any big differences from this to the
approach we currently use.
> What do you think ?
>
> [1] https://github.com/wso2/carbon-kernel/blob/master/core/pom.xml#L28
> [2] https://maven.apache.org/guides/mini/guide-naming-conventions.html
> [3]
> https://github.com/wso2/msf4j/blob/master/analytics/msf4j-analytics/pom.xml#L29
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
--
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Common configuration for publishing events from carbon servers to DAS/CEP
This new change is only for OSGi based servers in the platform right? Are
there any changes for standalone data publishing API's used with non-OSGi
servers in the platform or is it still the same as before? We have AS 6.0.0
which is based on pure tomcat and currently we are using the minimum
required data publishing libs and the standalone data publishing API's to
publish HTTP stats to DAS.
On Mon, Mar 14, 2016 at 4:51 PM, Malith Dhanushka <mal...@wso2.com> wrote:
> Hi all,
>
> Please follow the steps bellow when publishing events from carbon servers
> to DAS/CEP. Here we keep the DAS/CEP server location in
> CARBON_HOME/repository/deployment/server/eventpublishers directory and this
> is common across platform.
>
> - Install the Event Publisher Aggregate feature from p2_repo [1]
>
> - Install Registry Core feature if not installed
>
> - Create event stream and deploy that to
> CARBON_HOME/repository/deployment/server/eventstreams
>
> - Create publishers for the created stream and deploy that to
> CARBON_HOME/repository/deployment/server/eventpublishers
> Following is a sample configuration,
>
>
> http://wso2.org/carbon/eventpublisher;>
>
>
>
> admin
> thrift
> non-blocking
> 0
> tcp://localhost:7611
> X
>
>
>
> - Publish events to the created stream using
> org.wso2.carbon.event.stream.core.EventStreamService OSGI service.
> Following is a sample code snippet.
>
> Event event = new Event();
> event.setTimeStamp(System.currentTimeMillis());
> event.setStreamId("streamTest:1.0.0");
> event.setPayloadData(new Object[]{data});
> eventStreamService.publish(event);
>
> Please note that Event Publisher Aggregate feature is not yet included
> in carbon feature repo. It will be available with the immediate analytics
> feature release.
>
> [1]
> https://github.com/wso2/carbon-analytics-common/tree/master/features/event-publisher/org.wso2.carbon.event.publisher.aggregate.feature
>
> Thanks,
> Malith
> --
> Malith Dhanushka
> Senior Software Engineer - Data Technologies
> *WSO2, Inc. : wso2.com <http://wso2.com/>*
> *Mobile* : +94 716 506 693
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
--
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Supporting Carbon Metrics on Carbon 5 based products
> https://docs.wso2.com/display/MB300/Using+Messaging+Metrics >> >> >> > >> >> >> > This is one of main features in Carbon Metrics. >> >> >> > >> >> >> > The Metrics configurations are done in >> >> >> > "$CARBON_HOME/repository/conf/metrics.xml". The configuration is >> in >> >> >> > XML. >> >> >> > >> >> >> > If we are supporting Carbon Metrics in Carbon 5, I think following >> >> >> > needs >> >> >> > to >> >> >> > be done. >> >> >> > >> >> >> > Use latest Carbon P2 Plugin and update Metrics features to be >> >> >> > compatible >> >> >> > with Carbon 5 >> >> >> > Use YAML for configuration. >> >> >> > Admin services for Metrics Data fetching need to be converted as >> REST >> >> >> > services. >> >> >> > Remove Management Console UIs as there is no support for >> Management >> >> >> > Console >> >> >> > UIs in Carbon 5. >> >> >> > Set source and target Java version to Java 8. We can use Java 8 >> >> >> > features. >> >> >> > >> >> >> > If we remove Management Console UIs, how can we implement the UIs >> to >> >> >> > visualize Metrics data? >> >> >> > >> >> >> > I heard that we should use only DAS for visualizing Metrics. But I >> >> >> > prefer to >> >> >> > have separate UI to visualize the metrics from the database. Then >> we >> >> >> > can >> >> >> > use >> >> >> > Metrics UIs without depending on WSO2 DAS. >> >> >> > >> >> >> > If we don't want to have a UI, we will have to drop the JDBC >> reporter >> >> >> > as >> >> >> > well. >> >> >> > >> >> >> > Question to CEP Team: There is another UI to show hierarchical >> >> >> > metrics. >> >> >> > What >> >> >> > will happen to that in Carbon 5? >> >> >> > >> >> >> > How can we implement REST services in Carbon 5? (We may not need >> this >> >> >> > if >> >> >> > we >> >> >> > are not developing any UIs) >> >> >> > >> >> >> > By default, Metrics data are stored in local H2 database. Can we >> use >> >> >> > the >> >> >> > same approach in Carbon 5? (This is not needed if we stop using >> the >> >> >> > JDBC >> >> >> > reporter). >> >> >> > >> >> >> > There is also a properties file to configure Metric Levels. I hope >> >> >> > that's >> >> >> > not a problem. >> >> >> > >> >> >> > The plan is to use v2.0.0 for Metrics release with Carbon 5. We >> can >> >> >> > maintain >> >> >> > v1.x.x branch for Carbon 4.x.x products. >> >> >> > >> >> >> > Currently the WSO2 Gateway and MSF4J uses Carbon Metrics as Maven >> >> >> > Dependencies. We need a proper Carbon 5 supported release to >> >> >> > integrate >> >> >> > Carbon Metrics to these products. >> >> >> > >> >> >> > I really appreciate your feedback on this. >> >> >> > >> >> >> > Thanks! >> >> >> > >> >> >> > Best Regards, >> >> >> > >> >> >> > -- >> >> >> > Isuru Perera >> >> >> > Associate Technical Lead | WSO2, Inc. | http://wso2.com/ >> >> >> > Lean . Enterprise . Middleware >> >> >> > >> >> >> > about.me/chrishantha >> >> >> > Contact: +IsuruPereraWSO2 >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Ramith Jayasinghe >> >> >> Technical Lead >> >> >> WSO2 Inc., http://wso2.com >> >> >> lean.enterprise.middleware >> >> >> >> >> >> E: ram...@wso2.com >> >> >> P: +94 777542851 >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > S. Suhothayan >> >> > Technical Lead & Team Lead of WSO2 Complex Event Processor >> >> > WSO2 Inc. http://wso2.com >> >> > lean . enterprise . middleware >> >> > >> >> > cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ >> >> > twitter: http://twitter.com/suhothayan | linked-in: >> >> > http://lk.linkedin.com/in/suhothayan >> >> >> >> >> >> >> >> -- >> >> Ramith Jayasinghe >> >> Technical Lead >> >> WSO2 Inc., http://wso2.com >> >> lean.enterprise.middleware >> >> >> >> E: ram...@wso2.com >> >> P: +94 777542851 >> > >> > >> > >> > >> > -- >> > S. Suhothayan >> > Technical Lead & Team Lead of WSO2 Complex Event Processor >> > WSO2 Inc. http://wso2.com >> > lean . enterprise . middleware >> > >> > cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ >> > twitter: http://twitter.com/suhothayan | linked-in: >> > http://lk.linkedin.com/in/suhothayan >> >> >> >> -- >> Ramith Jayasinghe >> Technical Lead >> WSO2 Inc., http://wso2.com >> lean.enterprise.middleware >> >> E: ram...@wso2.com >> P: +94 777542851 >> > > > > -- > Isuru Perera > Associate Technical Lead | WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > about.me/chrishantha > Contact: +IsuruPereraWSO2 <https://www.google.com/+IsuruPereraWSO2/about> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [MB] Generalizing the transport model and Revamping MQTT transport
Are we extending and generalizing the already available transports + messaging abstraction or is this specifically designed for MB use-case? On Thu, Mar 10, 2016 at 7:23 PM, Pamod Sylvester <pa...@wso2.com> wrote: > Hi All, > > Further to the discussion in [1], following is a design derived to revamp > the existing MQTT transport, > > *Goals of the effort * > > 1) Introduce a generalized architecture for MB Netty based transport. > (common functions which will be applicable for all protocols > implementations in general MQTT,AMQP, Websockets etc would be abstracted > out) > 2) Revamp MQTT transport using this generalized architecture. > Current MQTT library we use for the transport *Moquette [2] *internally > handles events through an inbound and a outbound disruptor ring before > handing it over to the andes core, which adds an additional latency the > goal of this effort is to remove the disruptors off the library and use > only the content encoders and decoders of it which in return will allow > boosting of the performance. Another aspect of this effort is to adopt to > Netty 4 APIs for protocol handling which has introduced major > performance improvements. > > *Design* > > [image: Inline image 1] > > As depicted above in the diagram, following is a description, > > 1) *Server : *Would be used to control the execution/lifecycle of the > Netty based server implementation. The idea is to use > *CarbonTransportInitializer > [3]* to invoke/initialize the server implementation. > 2) *AbstractServer* : Will include the most common functionality that > should be included for any Netty based transport implementation (i.e Netty, > AMQP, Websockets) this will have common methods which are generic to all > transport implementations as well as an abstract method i.e " > *createPipeLine()*". > Between transports what would differ is the chain of handlers, hence any > transport implementation extending this class (i.e MQTTServer/AMQPServer) > should override *createPipeLine()* and define the set of handlers > specific to its protocol. > 3) *Broker *: Each handler defined in the Netty pipeline will perform > actions such as encoding/decoding incoming streams and > serializing/deserializing them into messages, these messages will be a set > of commands i.e CONNECT,PUBLISH, SUBSCRIBE, ACKNOWLEDGE and based on the > commands the message should be handled differently, the way a given message > is handled will differ based on different versions of the protocol. *Broker > *Interface would abstract between the messages and the execution of the > commands (message handling semantics) so that it will help adopt to > supporting different versions of same protocols i.e MQTT 3.1, MQTT 3.1.1, > AMQP .91, AMQP 1.0 > 4) *IConnector *: When messages are being handled (semantically) through > the *Broker, *there will be different storage requirements i.e primarily > adding the message to distributed store (andes core), messages would be > expected to be handled in memory etc which requires an abstraction between > the brokering semantics and the storage connectivity. Different stores > wishing to process the messages could write its connector implementing > IConnector. > > Please do share your thoughts/suggestions on this approach. > > [1] [Architecture][MB] Abstracting transport layer from core > [2] https://github.com/andsel/moquette > [3] > https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonTransportInitializer.java > > Thanks, > Pamod > > > -- > *Pamod Sylvester * > > *WSO2 Inc.; http://wso2.com <http://wso2.com>* > cell: +94 77 7779495 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Analytics][APIM] - Implement Geo location graph in Analytics
n operation would not incur much of a performance hit and it >>>>>>> won't be >>>>>>> as prohibitive as a normal range query in a cache. If that is the case, >>>>>>> I >>>>>>> think we can go with the approach suggested by Sanjeewa. >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>>> >>>>>>>>> Please find my comments about both the approaches. >>>>>>>>> >>>>>>>>> 1. Having an in-memory cache would speedup things but based on the >>>>>>>>> IPs in the data set, there could be number of entries for IPs in the >>>>>>>>> same >>>>>>>>> range. One problem with this approach is that, if there is a server >>>>>>>>> restart, the initial script execution would take a lots of time. Also >>>>>>>>> based >>>>>>>>> on certain scenarios(high number of different IPs) the cache would >>>>>>>>> not have >>>>>>>>> a significant effect on script execution performance. >>>>>>>>> >>>>>>>>> 2. Having a DB based cache would persist the data even on a >>>>>>>>> restart and the data fetching query would be searching for an specific >>>>>>>>> value(not a range query as against the max-mind DB). But the downside >>>>>>>>> is >>>>>>>>> that for a cache miss there would be minimum 3 DB queries (one for the >>>>>>>>> cache table lookup and one for the max-mind db lookup and one for the >>>>>>>>> cache persistence). >>>>>>>>> >>>>>>>>> That is why we have initiated this thread to finalize the caching >>>>>>>>> approach we should take. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Janaka >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> sanjeewa. >>>>>>>>>> >>>>>>>>> >>>>>>> Thanks, >>>>>>> Lasantha >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>>> On Fri, Mar 4, 2016 at 3:12 PM, Tharindu Dharmarathna < >>>>>>>>>> tharin...@wso2.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> We are going to implement Client IP based Geo-location Graph in >>>>>>>>>>> API Manager Analytics. When we go through the ways of doing in [1] >>>>>>>>>>> , we >>>>>>>>>>> selected [2] as the most suitable way to do. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Overview of max-mind's DB.* >>>>>>>>>>> >>>>>>>>>>> As the structure of the db (attached in image), They have two >>>>>>>>>>> tables which incorporate to get the location. >>>>>>>>>>> >>>>>>>>>>> Find geoname_id according to network and get Country,City from >>>>>>>>>>> locations table. >>>>>>>>>>> >>>>>>>>>>> *Limitations* >>>>>>>>>>> >>>>>>>>>>> As their database dump we couldn't directly process the ip from >>>>>>>>>>> those tables. We need to check the given ip is in between the >>>>>>>>>>> network min >>>>>>>>>>> and max ip. This query get some long time (10 seconds in indexed >>>>>>>>>>> data). If >>>>>>>>>>> we directly do this from spark script for each and every ip which in >>>>>>>>>>> summary table (regardless if ip is same from two row data) will >>>>>>>>>>> query from >>>>>>>>>>> the tables. Therefore this will incur the performance impact on >>>>>>>>>>> this graph. >>>>>>>>>>> >>>>>>>>>>> *Solution* >>>>>>>>>>> >>>>>>>>>>> 1. Implement LRU cache against ip address vs location. >>>>>>>>>>> >>>>>>>>>>> This will need to implement on custom UDF in Spark. If ip >>>>>>>>>>> querying from spark available in cache it will give the location >>>>>>>>>>> from it , >>>>>>>>>>> IF it is not It will retrieve from DB and put into the cache. >>>>>>>>>>> >>>>>>>>>>> 2. Persist in a Table >>>>>>>>>>> >>>>>>>>>>> ip as the primary key and Country and city as other columns and >>>>>>>>>>> retrieve data from that table. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please feel free to give us the most suitable way of doing this >>>>>>>>>>> solution?. >>>>>>>>>>> >>>>>>>>>>> [1] - Implementing Geographical based Analytics in API Manager >>>>>>>>>>> mail thread. >>>>>>>>>>> >>>>>>>>>>> [2] - http://dev.maxmind.com/geoip/geoip2/geolite2/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Thanks* >>>>>>>>>>> >>>>>>>>>>> *Tharindu Dharmarathna* >>>>>>>>>>> Associate Software Engineer >>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>> >>>>>>>>>>> mobile: *+94779109091 <%2B94779109091>* >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>> WSO2 Inc. >>>>>>>>>> Mobile : +94713068779 >>>>>>>>>> >>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Janaka Ranabahu* >>>>>>>>> Associate Technical Lead, WSO2 Inc. >>>>>>>>> http://wso2.com >>>>>>>>> >>>>>>>>> >>>>>>>>> *E-mail: jan...@wso2.com <http://wso2.com>**M: **+94 718370861 >>>>>>>>> <%2B94%20718370861>* >>>>>>>>> >>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sachith Withana >>>>>>>> Software Engineer; WSO2 Inc.; http://wso2.com >>>>>>>> E-mail: sachith AT wso2.com >>>>>>>> M: +94715518127 >>>>>>>> Linked-In: <http://goog_416592669> >>>>>>>> https://lk.linkedin.com/in/sachithwithana >>>>>>>> >>>>>>>> ___ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Lasantha Fernando* >>>>>>> Senior Software Engineer - Data Technologies Team >>>>>>> WSO2 Inc. http://wso2.com >>>>>>> >>>>>>> email: lasan...@wso2.com >>>>>>> mobile: (+94) 71 5247551 >>>>>>> >>>>>>> ___ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Tharindu Dharmarathna*Associate Software Engineer >>>>>> WSO2 Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> mobile: *+94779109091 <%2B94779109091>* >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> *Lasantha Fernando* >>>> Senior Software Engineer - Data Technologies Team >>>> WSO2 Inc. http://wso2.com >>>> >>>> email: lasan...@wso2.com >>>> mobile: (+94) 71 5247551 >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Tharindu Dharmarathna*Associate Software Engineer >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: *+94779109091 <%2B94779109091>* >>> >> >> >> >> -- >> >> *Tharindu Dharmarathna*Associate Software Engineer >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: *+94779109091 <%2B94779109091>* >> > > > > -- > *Janaka Ranabahu* > Associate Technical Lead, WSO2 Inc. > http://wso2.com > > > *E-mail: jan...@wso2.com <http://wso2.com>**M: **+94 718370861 > <%2B94%20718370861>* > > Lean . Enterprise . Middleware > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IS] Improvements to Claim Management
e removed and moved to >>Identity claim management. >>- >> >>The user.core claims will be stored in memory. DefaultClaimManager >>will be a file based claim manager. >>- >> >>Reading the claim-config.xml and parsing it as claimConfig object >> will be done by the user.core. >>- >> >>All the CRUD operations with the database will be handled by the >>identity.claim.mgt. >>- >> >>Once the claims are received from the user.core, Identity claim >>manager will categorize the claims (local and additional claims) and >>prepare claim mappings. >> >> >> Database level changes >> >>- >> >>UM_CLAIM table normalized into four tables >> >> >> [image: 1.png] >> >> >>- >> >>UM_CLAIM >> >> >> [image: 2.png] >> >> >>- >> >>UM_CLAIM_MAPPING, will hold the relationship between local claims and >>other claims >> >> >> [image: 3.png] >> >> >> >> >>- >> >>UM_CLAIM_MAPPED_ATTRIBUTE, will hold the mapped attributes of local >>claims >> >> >> [image: 4.png] >> >> >>- >> >>UM_CLAIM_META_DATA , will hold the metadata information of claims >> >> >> [image: 5.png] >> >> user.api changes >> >>- >> >>Claim (C)- only contains claimUri to uniquely identify a given claim >>and the value of the claim. Which previously contains, >> >> >> >>- private String *claimUri*; >> - private boolean readOnly; >> - private boolean checkedAttribute; >> - private String displayTag; >> - private String description; >> - private boolean supportedByDefault; >> - private boolean required; >> - private String regEx; >> - private String dialectURI; >> - private String *value*; >> - private int displayOrder; >> >> >> >> >>- ClaimManager (I)- Some methods are removed which were involved with >>dialects and meta data retrieval. Which are, >> >> >>- ClaimMapping[] getAllRequiredClaimMappings(). >> - ClaimMapping[] getAllSupportClaimMappingsByDefault(). >> - ClaimMapping[] getAllClaimMappings(String dialectUri) >> >> user.core changes >> >> + FileBasedClaimbuilder (C) - read claimConfig.xml and prepare >> claimConfig objects with claim and meta data information. >> >> + ClaimManagerFactory (I) - to return tenant-specific claim manager >> object. >> >> + ClaimConfig (C) - to hold the claim and meta data info. >> identtity.claim.mgt.ui >> >>- >> >>When creating a new dialect or new(non-wso2) claim, a wso2(local) >>claim needs to be selected from the list. >> >> >> >> [image: 6.png] >> >> >> >>- >> >>Improved claim management UI for user store based claims. >> >> >> [image: Untitled-2 copy1.jpg] >> >> Thanks and Regards, Chanuka. >> -- >> Chanuka Dissanayake >> *Software Engineer | **WSO2 Inc.*; http://wso2.com >> >> Mobile: +94 71 33 63 596 >> Email: chan...@wso2.com >> >> -- >> Chanuka Dissanayake >> *Software Engineer | **WSO2 Inc.*; http://wso2.com >> >> Mobile: +94 71 33 63 596 >> Email: chan...@wso2.com >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Maduranga Siriwardena > Software Engineer > WSO2 Inc. > > email: madura...@wso2.com > mobile: +94718990591 > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AS 6.0.0] HTTP Monitoring dashboard - Why are we parsing the User-Agent header in the event builder?
Yes, we need to minimize such overhead at data publishing side and do these type of processing during summarization as Janaka suggested. On Wed, Mar 9, 2016 at 10:58 AM, Manoj Kumara <ma...@wso2.com> wrote: > I too think its a valid concern. +1 to publish the complete header as it > is. > > @Lochana, > Please note this during HTTP Monitoring Dashboard task when you are > extracting the information. > > Regards, > Manoj > > *Manoj Kumara* > WSO2 Inc. *| **lean. enterprise. middleware.* > *Mobile:* +94 713 448188 > > On Wed, Mar 9, 2016 at 10:42 AM, Nathasha Naranpanawa <natha...@wso2.com> > wrote: > >> Hi all, >> >> The user-agent information were extracted at event publishing time mainly >> considering that data analyzing using scripts will be made easier at the >> Dashboard Server. >> >> We are going to change the current implementation by publishing the whole >> user-agent string considering all the performance issues and other concerns. >> >> Thanks, >> >> >> >> >> On Tue, Mar 8, 2016 at 10:53 PM, Janaka Ranabahu <jan...@wso2.com> wrote: >> >>> Hi App Server team, >>> >>> According to the code in [1], the user-agent string is parsed and some >>> of the information are extracted from the user-agent at event publishing >>> time. Could you guys please clarify why you guys haven't published the >>> whole user-agent string to DAS and use a UDF to extract the corresponding >>> data at data summarization time? >>> >>> There are several concerns I see in the current approach. >>> 1. This will add additional overhead to the server when processing each >>> request as it has to process the user-agent string to filter out these data. >>> 2. We are currently limiting the information that can be extracted from >>> the user-agent at the data publishing time. If we publish the whole >>> user-agent string, then the users have the option of coming up with a new >>> analytics script to extract any data from the user-agent. >>> 3. If we encounter a bug/limitation or upgrade/replace in the user-agent >>> processing library, then we have to change/update the event publisher code. >>> Having a user defined function in DAS to extract the information from the >>> user-agent would address this scenario as we do not have to do any changes >>> to the data publishers. >>> 4. We need to parse the user-agent from all the places where we publish >>> the HTTP data. Based on the current plans, if we are going to integrate the >>> HTTP Monitoring dashboard to API Manager, then from the API Manager side, >>> we also have to parse the user-agent and extract the data from the gateway >>> nodes before publishing the data. >>> >>> Therefore I see that the better approach would be to publish the whole >>> user-agent string and extract data from DAS data summarization time. >>> >>> WDYT? >>> >>> Thanks, >>> Janaka >>> >>> [1] >>> https://github.com/wso2/product-as/blob/wso2as-6.0.0/modules/http-statistics-monitoring/src/main/java/org/wso2/appserver/monitoring/utils/EventBuilder.java >>> >>> -- >>> *Janaka Ranabahu* >>> Associate Technical Lead, WSO2 Inc. >>> http://wso2.com >>> >>> >>> *E-mail: jan...@wso2.com <http://wso2.com>**M: **+94 718370861 >>> <%2B94%20718370861>* >>> >>> Lean . Enterprise . Middleware >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Nathasha Naranpanawa >> Software Engineering Intern >> WSO2 Inc. >> >> Email: natha...@wso2.com >> Mobile: +94775496142 >> LinkedIn: https://lk.linkedin.com/in/nathashanaranpanawa >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Web Application Statistics Monitoring for Application Server 6.0.0
;> Dev mailing list >>>>> d...@wso2.org >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> -- >>>> >>>> *Nuwan Chamara Pallewela* >>>> >>>> >>>> *Software Engineer* >>>> >>>> *WSO2, Inc. *http://wso2.com >>>> *lean . enterprise . middleware* >>>> >>>> Email *nuw...@wso2.com <nuw...@wso2.com>* >>>> Mobile *+94719079739 <%2B94719079739>@* >>>> >>>> >>>> >>> >>> >>> -- >>> -- >>> >>> *Nuwan Chamara Pallewela* >>> >>> >>> *Software Engineer* >>> >>> *WSO2, Inc. *http://wso2.com >>> *lean . enterprise . middleware* >>> >>> Email *nuw...@wso2.com <nuw...@wso2.com>* >>> Mobile *+94719079739 <%2B94719079739>@* >>> >>> >>> >>> ___ >>> Dev mailing list >>> d...@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *Imesh Gunaratne* >> Senior Technical Lead >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: http://imesh.gunaratne.org >> Lean . Enterprise . Middleware >> >> > > > -- > Nathasha Naranpanawa > Software Engineering Intern > WSO2 Inc. > > Email: natha...@wso2.com > Mobile: +94775496142 > LinkedIn: https://lk.linkedin.com/in/nathashanaranpanawa > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] MSF4J archetype is not listed in Maven archetype-catalog
IIRC, the archetype catalogs are normally updated on every Sundays. Since we released the archetype last week, it should have been indexed and updated yesterday. We could wait for a one or two days and check again via the jira we created for this, if the archetype is not updated in the catalog list. @Manuri, in the mean time could we check whether is there any differences between the two? On Mon, Feb 22, 2016 at 11:39 AM, Sagara Gunathunga <sag...@wso2.com> wrote: > > It seems MSF4J archetype is not listed in Maven central archetype-catalog > file [1], this leads few major usability issues. > > 1. ) Most popular approach to use an archetype is, run archetype:generate > goal with -Dfilter option to get interactive mode, this is not supported > for MSF4J due to above issue. > > e.g : "mvn archetype:generate -Dfilter=org.wso2.msf4j" is not working. > > > 2.) Also if someone run archetype:generate goal only, he should have > provided a list of archetypes to pick a specific one interactively, due to > same issue above list does not contains an entry for MSF4J. > > e.g : "mvn archetype:generate " is not working. > > > > 3.) ATM only way to use above archetype is, provide all 8 inputs as > options for archetype:generate goal (non- interactive mode), that is not > widely used and personally I never tend to use that option. > > e.g : > mvn archetype:generate -DarchetypeGroupId=org.wso2.msf4j \ > -DarchetypeArtifactId=msf4j-microservice -DarchetypeVersion=1.0.0 \ > -DgroupId=org.example -DartifactId=Hello-Service -Dversion=1.0.0-SNAPSHOT \ > -Dpackage=org.example.service -DserviceClass=HelloService > > > In the meantime I noticed archetypes we provided for Carbon kernel 5 is > listed in archetype-catalog.xml[1] file and support for all 3 modes (e.g > - mvn archetype:generate -Dfilter=org.wso2.carbon ) I guess we are missing > something in MSF4J archetype, can someone look into this please ? > > > > [1] - http://repo1.maven.org/maven2/archetype-catalog.xml > > > > > Thanks ! > -- > Sagara Gunathunga > > Architect; WSO2, Inc.; http://wso2.com > V.P Apache Web Services;http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Improving MSF4J Interceptors to support passing objects to resource methods
+1 to have this. In a normal JAX-RS app, the same requirement to access
servlet session object is by using "@Context HttpServletRequest request"
within the resource methods. I believe we are using our own session object
here right?
Can you also explain how can we process annotations independently with this
model?
On Wed, Feb 10, 2016 at 2:23 PM, Samiyuru Senarathne <samiy...@wso2.com>
wrote:
> *What is an MSF4J Interceptor?*
> In MSF4J interceptors are capable of processing an Http request before or
> after the Http request arrives a resource methods. Interceptors implement
> the *org.wso2.msf4j.Interceptor* interface.
>
> public interface Interceptor {
>
> boolean preCall(HttpRequest request, HttpResponder responder,
> ServiceMethodInfo serviceMethodInfo);
>
> void postCall(HttpRequest request, HttpResponseStatus status,
> ServiceMethodInfo serviceMethodInfo);
> }
>
>
>
> *Problem*
> With the current implementation of MSF4J, there is no way for MSF4J
> interceptors to communicate with resource methods. That means, if an
> interceptor is preprocessing a request and creates an object model out of
> the request that needs to be accessible to the corresponding resource
> method, how can the interceptor pass the created object model to the
> resource method?
>
> One example of this situation is implementing an interceptor for handling
> sessions. In this case, the session interceptor will process the http
> request and create a session object. This session object should then be
> passed to the resource methods. With current implementation there is no
> proper way to do this.
>
> *Suggested Solution*
> Currently the *ServiceMethodInfo* parameter in
> *org.wso2.msf4j.Interceptor* contains only an attribute map and
> *a java.lang.reflect.Method* type reference to the resource method.
>
> We can improve this class to support type based parameter injection to the
> resource method. That means,
>
>- We rename *ServiceMethodInfo* class to a name similar to
>*ServiceMethodContext*
>- Then we introduce an *inject(Object parameter)* method to this
>context class. Interceptors can use this method to inject the objects that
>they create to the resource method context.
>
> IE: If we consider a session interceptor,
>
> servicemethodCtx.inject(session) // session object is is injected to the
> resource method context
>
> Further we can introduce methods to *ServiceMethodInfo* to query the
> resource method's parameter support. This helps to limit processing
> information in interceptors that resource methods does not accept.
>
>
>- Resource methods can use the *@Context* annotation to consume the
>available objects in the resource method's context as shown bellow.
>
> @GET
>
> public Response helloService(@Context Session session) {
>
> // If the session interceptor is available the session will be injected to
> the resource method by matching the type of the @Context
> annotated parameters
>
>
>
> }
>
> Further, with this solution, we can even consider to break current
> centralised annotation processing logic into individual interceptors that
> process a certain kind of annotation. This will improve modularity,
> scalability as well as the consistency of the design.
>
> WDYT?
>
>
> Best Regards,
> Samiyuru
>
>
> --
> Samiyuru Senarathne
> *Software Engineer*
> Mobile : +94 (0) 71 134 6087
> samiy...@wso2.com
>
--
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Distributed Coordination in C5 was [Hangout Session] With Kernel Team On MB C5 Plans @ Mon Feb 8, 2016 2pm - 3pm (ram...@wso2.com)
On a related note, with hazlecast 3.6, the proper OSGi support also available. We don't need to create an orbit and hazelcast bundle it self exposes the OSGi service [1]. So this would minimize the maintenance effort from our side as what we have to do is only write the code needed to initialize the hazelcast instance (and also add the leader election implementation logic). Also we can use the hazelcast.xml as the configuration file rather than creating a new one. Thanks, Kishanthan. [1] https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/osgi/impl/Activator.java On Tue, Feb 9, 2016 at 10:00 AM, Kasun Indrasiri <ka...@wso2.com> wrote: > > > On Tue, Feb 9, 2016 at 9:56 AM, Ramith Jayasinghe <ram...@wso2.com> wrote: > >> we are +1 for Hazelcast. we use it main for group communication (and >> member discovery). >> >> On Mon, Feb 8, 2016 at 8:31 PM, Srinath Perera <srin...@wso2.com> wrote: >> > Moving to arch@ >> > >> > CEP ( for Storm based version), MB ( for base algo), ESB ( for tasks) >> are >> > known cases. For those, we can use Hazelcast ( they can use it >> directly). >> > >> > > Yeah, in ESB we used it for Polling Inbound endpoints (JMS, VFS etc.), > Message Processor coordination and Scheduled Task coordination (the > underlying implementation is based on ntasks). > Regarding the # of nodes, say if we have few hundreds of nodes which > requires coordination for aforementioned functionality, I guess Hazelcast > still can gracefully handle that use case too. > >> > Hazelcast works OK with small number of nodes. AFAIK, there is no better >> > solution ( we use Zookeeper before) unless there is something new. >> > >> > --Srinath >> > >> > >> > >> > On Mon, Feb 8, 2016 at 8:07 PM, Sameera Jayasoma <same...@wso2.com> >> wrote: >> >> >> >> Looks like several products require distributed coordination. We need >> to >> >> evaluate these requirements and come up with a solution. >> >> >> >> Hazelcast is used in C4 based products to achieve distributed >> >> coordination. Not sure whether we should go ahead with Hazelcast after >> all >> >> the issues we've faced so far with it. >> >> >> >> Kasun, Ramith and Suho can you guys explain the requirement to use the >> >> distributed coordination. >> >> >> > >> Thanks, >> >> Sameera. >> >> >> > >> >> >> >> -- >> Ramith Jayasinghe >> Technical Lead >> WSO2 Inc., http://wso2.com >> lean.enterprise.middleware >> >> E: ram...@wso2.com >> P: +94 777542851 >> _______ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [MB] Abstracting transport layer from core
For this requirement, can we follow the same approach of how carbon-transports and carbon-messaging layers have been developed with the abstraction where you can plugin any transports and/or any message types associated with transports for processing? On a related note, In kernel we have the managed transports concept, where the kernel manages the lifecycle of all transports such as start, stop, begin maintenance, etc [1]. Thanks, Kishanthan. [1] https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/transports/CarbonTransport.java On Tue, Feb 9, 2016 at 4:36 PM, Selvaratnam Uthaiyashankar <shan...@wso2.com > wrote: > > > On Tuesday, February 9, 2016, Pamod Sylvester <pa...@wso2.com> wrote: > >> Hi All, >> >> Currently transports (AMQP,MQTT) in MB are coupled with the andes core >> (same bundle). We're in process of identifying a way to abstract the >> transports from its core, so that we bring in a pluggable architecture >> which would allow plug in the relevant transport to the broker on demand. >> This will help to featherweight MB. >> >> The abstract message flow would look like the following, >> [image: Inline image 2] >> As depicted in the above diagram, if the transport is abstracted into a >> separate bundle, there will be circular dependency between the core and the >> transport. i.e when messages are published 'transport' will need to call >> services in the 'core' and when messages are distributed to the subscribers >> the 'core' will need to call services in the 'transport' >> > > When we have multiple transports, how the core knows which transport to > call to distribute messages to subscribers? Isn't the core suppose to call > an "interface", so that the core doesn't know about any concrete > transports? If so, there won't be any circular dependencies, right? > > > >> >> Currently we're in the process of identifying a solution for the circular >> dependency, making the cardinality of one of the referencing service >> optional [1] could be a solution, but we need to understand whether there's >> a better approach for this. >> >> WDYT ? >> >> [1] >> http://docs.spring.io/osgi/docs/current/api/org/springframework/osgi/service/importer/support/Cardinality.html >> >> Thanks, >> Pamod >> -- >> *Pamod Sylvester * >> >> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >> cell: +94 77 7779495 >> > > > -- > S.Uthaiyashankar > VP Engineering > WSO2 Inc. > http://wso2.com/ - "lean . enterprise . middleware" > > Phone: +94 714897591 > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [MSF4j] Creating an archetype for a microservice
nd keep >>>> a map of students inside MicroService class. >>>> Any suggestions on this? >>>> >>>> >>>> Thank you. >>>> >>>> >>>> >>>> -- >>>> >>>> *Manuri Amaya Perera* >>>> >>>> *Software Engineer* >>>> >>>> *WSO2 Inc.* >>>> >>>> *Blog: http://manuriamayaperera.blogspot.com >>>> <http://manuriamayaperera.blogspot.com>* >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Imesh Gunaratne* >>> Senior Technical Lead >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 >>> W: http://imesh.gunaratne.org >>> Lean . Enterprise . Middleware >>> >>> >> >> -- >> >> *Manuri Amaya Perera* >> >> *Software Engineer* >> >> *WSO2 Inc.* >> >> *Blog: http://manuriamayaperera.blogspot.com >> <http://manuriamayaperera.blogspot.com>* >> >> > > > -- > > *Manuri Amaya Perera* > > *Software Engineer* > > *WSO2 Inc.* > > *Blog: http://manuriamayaperera.blogspot.com > <http://manuriamayaperera.blogspot.com>* > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Using annotations for declarative services compoenets
+1
bundle-plugin it self can be used to process these annotations and we do
not have to use any other plugins.
On Wed, Jan 13, 2016 at 12:13 PM, Aruna Karunarathna <ar...@wso2.com> wrote:
> Hi Kishanthan,
>
> Have we added this to the documentation?. AFAIK we haven't.
>
> Shall we add this to documentation, since now people will write scr
> components for C5 features and it's better we can make awareness of this
> new
> annotation model. And found your blog post which contain more information
> [1].
>
> [1].
> https://kishanthan.wordpress.com/2014/03/29/using-annotation-with-osgi-declarative-services/
>
> Regards,
> Aruna
>
> On Sat, Mar 29, 2014 at 5:01 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> Hi All,
>>
>> C5 project is now following the standardized annotation based model with
>> declarative service components, which is specified in the OSGi compendium
>> specification [1]. These standard annotation related classes are available
>> with the following dependency.
>>
>>
>> org.eclipse.osgi
>> org.eclipse.osgi.services
>>
>>
>> Apache Felix scr.ds-annotations and maven-scr-plugin [2] can be used to
>> process the annotated class and generate the component descriptors (the
>> meta files).
>>
>> Here is an example usage.
>>
>> @*Component*(
>> name = "org.wso2.carbon.kernel.internal.CommandProvider",
>> immediate = true
>> )
>>
>> public class CarbonKernelCommandProvider implements CommandProvider {
>>
>> private CarbonRuntime carbonRuntime;
>> private ServiceRegistration serviceRegistration;
>>
>> @*Activate*
>> public void registerCommandProvider(BundleContext bundleContext) {
>> serviceRegistration =
>> bundleContext.registerService(CommandProvider.class, this, null);
>> }
>>
>> @*Deactivate*
>> public void unregisterCommandProvider(BundleContext bundleContext) {
>> serviceRegistration.unregister();
>> }
>>
>> @*Reference*(
>> name = "carbon.runtime.service",
>> service = CarbonRuntime.class,
>> cardinality = ReferenceCardinality.MANDATORY,
>> policy = ReferencePolicy.DYNAMIC,
>> unbind = "unsetCarbonRuntime"
>> )
>> public void setCarbonRuntime(CarbonRuntime carbonRuntime) {
>> this.carbonRuntime = carbonRuntime;
>> }
>>
>> public void unsetCarbonRuntime(CarbonRuntime carbonRuntime) {
>> this.carbonRuntime = null;
>> }
>> }
>>
>> This will be documented for development with C5.
>>
>> Thanks,
>> Kishanthan.
>> [1] http://www.osgi.org/download/r5/osgi.cmpn-5.0.0.pdf
>> [2]
>> https://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-maven-scr-plugin-use.html
>>
>>
>> <https://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-maven-scr-plugin-use.html>
>> --
>> *Kishanthan Thangarajah*
>> Senior Software Engineer,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635
>> Blog - *http://kishanthan.wordpress.com
>> <http://kishanthan.wordpress.com>*
>> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Aruna Sujith Karunarathna *| Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 71 9040362 | Work: +94 112145345
> Email: ar...@wso2.com | Web: www.wso2.com
>
>
--
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IS] Move to symmetric data encryption from asymmetric encryption
On Fri, Nov 20, 2015 at 2:49 PM, Indunil Upeksha Rathnayake < indu...@wso2.com> wrote: > Hi all, > > Currently in Identity Server, *asymmetric encryption* is using as the > data encryption mechanism. Following issues has been occurred due to the > current implementation: > > 1) *Huge migration effort when Asymmetric key get expired* > > Currently we have a migration script for this. What it does is, we give > the list of registry paths that contain encrypted data, old key and new key > and the tool will decrypt using the old key and encrypt using the new key > and restore it. Issue with this approach is that it is not a scalable > solution because different products store data in different locations. We > have to maintain an exhaustive list of all of those places. Also the tool > is not future proof. When a new path is used to store encrypted data the > tool needs to be updated. > > 2) *The data length that can be encrypted is limited* > > With asymmetric key encryption the data length that can be encrypted is > limited by the private key length. > > *Following approach is suggested to overcome those issues: * > *Use a symmetric key to encrypt the data and use an asymmetric key to > encrypt that symmetric key.* > As per the suggested approach, in server startup, a symmetric key will be > generated. And that symmetric key will be encrypted using an asymmetric key > and will be stored either in registry or in file system. Apart from that, > the non encrypted symmetric key will be stored in own memory. > > > > Following scenarios has been considered in *IS cluster/ Muti-product > cluster setup*. In there, issues can be occurred, if trying to write to > the registry concurrently. > In cluster startup, all the nodes will try to generate a symmetric key and > store that key in registry as well as in their own memory. If the nodes in > the cluster are trying to write to the registry concurrently, some nodes > will be referring to invalid symmetric key and conflicts will be occurred > when decrypting by using the valid key in the registry. > > *As a solution for this, we are trying to go for following approach:* > *Before the very first encryption or decryption by any node, it will > compare the key it has generated(which is stored in memory) with the key in > the registry.* If the key is not matching, current key in it's memory > will be changed to the key which is in the registry. So that every node in > the cluster will be referring to the valid symmetric key(key stored in the > registry) for encrypting any data. > > > > Really appreciate any feedbacks and ideas on this approach. It also goes > without saying, any component doing encryption or decryption will wait for > the carbon.core bundle to get activated which contains the CryptoUtil class > which performs encryption and decryption. By the time carbon.core is > activated we can guarantee the the symmetric key has been written to > registry. > How are we going to make sure the above order at runtime? Are you going to depend on some OSGi service references? > > Also this will be a change in carbon-kernel. > @Kernel Team, we are hoping to do this change in a backward compatible > manner. Do you see any reason for this not to be added to kernel-4.4.3 ? > Are there going to be new API additions? > > Thanks and Regards > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Emailindu...@wso2.com > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IS] Move to symmetric data encryption from asymmetric encryption
We also need to think about migration and deployment effort. - Existing users of 4.4.0, 4.4.1 & 4.4.2 based products will still need to use old encryption when migrating, unless the existing data is decrypted and encrypted again with the new key. - If this is added to 4.4.3, then deploying products that are based on 4.4.3 and previous kernel versions together will have issues since they use different encryption approach. @Prabath, Johann, how can we address these concerns? On Mon, Nov 23, 2015 at 3:39 PM, Indunil Upeksha Rathnayake < indu...@wso2.com> wrote: > Hi Kishanthan, > > Yes. We are going to make sure the order at runtime by depending on OSGI > service references. There won't be any API changes, and will be > implemented in backward compatible manner. > > Thanks and Regards > > On Mon, Nov 23, 2015 at 2:57 PM, Kishanthan Thangarajah < > kishant...@wso2.com> wrote: > >> >> >> On Fri, Nov 20, 2015 at 2:49 PM, Indunil Upeksha Rathnayake < >> indu...@wso2.com> wrote: >> >>> Hi all, >>> >>> Currently in Identity Server, *asymmetric encryption* is using as the >>> data encryption mechanism. Following issues has been occurred due to the >>> current implementation: >>> >>> 1) *Huge migration effort when Asymmetric key get expired* >>> >>> Currently we have a migration script for this. What it does is, we give >>> the list of registry paths that contain encrypted data, old key and new key >>> and the tool will decrypt using the old key and encrypt using the new key >>> and restore it. Issue with this approach is that it is not a scalable >>> solution because different products store data in different locations. We >>> have to maintain an exhaustive list of all of those places. Also the tool >>> is not future proof. When a new path is used to store encrypted data the >>> tool needs to be updated. >>> >>> 2) *The data length that can be encrypted is limited* >>> >>> With asymmetric key encryption the data length that can be encrypted is >>> limited by the private key length. >>> >>> *Following approach is suggested to overcome those issues: * >>> *Use a symmetric key to encrypt the data and use an asymmetric key to >>> encrypt that symmetric key.* >>> As per the suggested approach, in server startup, a symmetric key will >>> be generated. And that symmetric key will be encrypted using an asymmetric >>> key and will be stored either in registry or in file system. Apart from >>> that, the non encrypted symmetric key will be stored in own memory. >>> >>> >>> >>> Following scenarios has been considered in *IS cluster/ Muti-product >>> cluster setup*. In there, issues can be occurred, if trying to write to >>> the registry concurrently. >>> In cluster startup, all the nodes will try to generate a symmetric key >>> and store that key in registry as well as in their own memory. If the nodes >>> in the cluster are trying to write to the registry concurrently, some nodes >>> will be referring to invalid symmetric key and conflicts will be occurred >>> when decrypting by using the valid key in the registry. >>> >>> *As a solution for this, we are trying to go for following approach:* >>> *Before the very first encryption or decryption by any node, it will >>> compare the key it has generated(which is stored in memory) with the key in >>> the registry.* If the key is not matching, current key in it's memory >>> will be changed to the key which is in the registry. So that every node in >>> the cluster will be referring to the valid symmetric key(key stored in the >>> registry) for encrypting any data. >>> >>> >>> >>> Really appreciate any feedbacks and ideas on this approach. It also goes >>> without saying, any component doing encryption or decryption will wait for >>> the carbon.core bundle to get activated which contains the CryptoUtil class >>> which performs encryption and decryption. By the time carbon.core is >>> activated we can guarantee the the symmetric key has been written to >>> registry. >>> >> >> How are we going to make sure the above order at runtime? Are you going >> to depend on some OSGi service references? >> >> >>> >>> Also this will be a change in carbon-kernel. >>> @Kernel Team, we are hoping to do this change in a backward compatible >>> manner. Do you see any reason for this not to be added to kernel-4.
Re: [Architecture] Equinox P2 and Carbon Kernel 5.0.0
On Wed, Nov 18, 2015 at 3:47 PM, Nuwan Dias <nuw...@wso2.com> wrote: > > > On Wed, Nov 18, 2015 at 3:45 PM, Sameera Jayasoma <same...@wso2.com> > wrote: > >> Hi Folks, >> >> Carbon Kernel 5.0-alpha does not contain any P2 libraries. But we use P2 >> for product building. IMHO there is no need to include P2 libraries to >> Carbon kernel. We can maintain P2 libraries in a separate feature in the >> platform space. Products which require feature management capability can >> install this P2 feature into their product during the build time. >> > > Don't all products require feature management capability? > Not every products IMO. For example, GW product will have only the features needed to function as a GW, and users would rarely want to install additional features on to it. >> If someone wants install command-line feature management capability to >> Carbon kernel, he/she can do so by installing p2 feature using a pom.xml >> based approach. >> >> Therefore we will not include P2 libraries for the C5 release. Please >> share your feedback on this. >> > +1. We can include this under the common platform features category. >> Thanks, >> Sameera. >> >> -- >> Sameera Jayasoma, >> Software Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: same...@wso2.com >> blog: http://blog.sameera.org >> twitter: https://twitter.com/sameerajayasoma >> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >> Mobile: 0094776364456 >> >> Lean . Enterprise . Middleware >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Nuwan Dias > > Technical Lead - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Need to do a 1.0 release of Carbon-transports
On Mon, Oct 26, 2015 at 6:42 PM, Kishanthan Thangarajah <kishant...@wso2.com > wrote: > We need the carbon-startup coordinator integrated with transports project. > I'm integrating and testing it now. We can merge it, test it and release it. > This PR [1] include the fixes needed for integrating the startup coordinator with transports project. Thanks, [1] https://github.com/wso2/carbon-transports/pull/9 > > On Mon, Oct 26, 2015 at 6:07 PM, Afkham Azeez <az...@wso2.com> wrote: > >> This is needed for the GW & MSS releases. Carbon transport currently only >> contains the Netty transport & it seems to be stable and no fixes or >> features have gone into it recently. >> >> So I think we can do a 1.0 release. >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **az...@wso2.com* <az...@wso2.com> >> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez* >> <http://twitter.com/afkham_azeez> >> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> > > > > -- > *Kishanthan Thangarajah* > Associate Technical Lead, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Need to do a 1.0 release of Carbon-transports
We need the carbon-startup coordinator integrated with transports project. I'm integrating and testing it now. We can merge it, test it and release it. On Mon, Oct 26, 2015 at 6:07 PM, Afkham Azeez <az...@wso2.com> wrote: > This is needed for the GW & MSS releases. Carbon transport currently only > contains the Netty transport & it seems to be stable and no fixes or > features have gone into it recently. > > So I think we can do a 1.0 release. > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **az...@wso2.com* <az...@wso2.com> > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] carbon-feature-plugin 2.0.0 Milestone 1 Released
>> *Dinusha Boteju* >>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>> *lean.enterprise.middleware.* >>>> >>>> email: dinus...@wso2.com <ruw...@wso2.com> >>>> phone:(+94) 776640275 <%28%2B94%29%2039736> >>>> >>> >>> >>> >>> -- >>> >>> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. >>> email: kasung AT spamfree wso2.com >>> linked-in: http://lk.linkedin.com/in/gajasinghe >>> blog: http://kasunbg.org >>> >>> >>> >>> ___ >>> Dev mailing list >>> d...@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Sameera Jayasoma, >> Software Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: same...@wso2.com >> blog: http://blog.sameera.org >> twitter: https://twitter.com/sameerajayasoma >> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >> Mobile: 0094776364456 >> >> Lean . Enterprise . Middleware >> >> > > > -- > > *Dinusha Boteju* > *Associate Tech Lead,* > *WSO2, Inc. http://wso2.com <http://wso2.com/> * > *lean.enterprise.middleware.* > > email: dinus...@wso2.com <ruw...@wso2.com> > phone:(+94) 776640275 <%28%2B94%29%2039736> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Retrying faulty CApps
+1, but there should be a limit for the number of retry right? On Thu, Aug 27, 2015 at 9:23 AM, Afkham Azeez <az...@wso2.com> wrote: > Yes this can be done. What should happen perhaps is if deploying even one > artifact in the capp fails, we need to undeploy all other artifacts in the > capp that got successfully deployed & then try redeployment periodically. > On Aug 24, 2015 11:41 AM, "Kasun Indrasiri" <ka...@wso2.com> wrote: > >> Hi, >> >> Is it possible to add this as a new feature at carbon level? I think when >> a CApp deployment initially fails due to intermittent resources/databases >> unavailability etc., it may be required to have a re-try mechanism for >> re-deploying artifacts without user intervention. >> >> Thanks. >> >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 77 556 5206 >> Blog : http://kasunpanorama.blogspot.com/ >> > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Carbon] [Kernel] Introducing a Clustering Membership Scheme Extension Point
But currently in C4, we initialize the cluster during the server startup finalization process, even after transports are initialized. So this should not be an issue. Anyway let's test this. On Fri, Jul 10, 2015 at 1:53 PM, Afkham Azeez az...@wso2.com wrote: Good question. We will have to do some sort of ordering to make sure that these services are available before the cluster initialization continues. On Fri, Jul 10, 2015 at 12:03 PM, Akila Ravihansa Perera raviha...@wso2.com wrote: Hi, Just out of curiosity, what happens if the OSGi service for custom membership scheme is not registered by the time kernel tries to initialize the cluster? Do we have to forcefully pause the kernel clustering initialization until the given membership scheme service is registered (within a bounded time)? Thanks. On Fri, Jul 10, 2015 at 10:49 AM, Kishanthan Thangarajah kishant...@wso2.com wrote: Yes. Instead of giving the implementation class name in carbon.xml (we will have to use Class.forName to load the class), we can use OSGi declarative services approach here. What we can do is, we will have the implementation in different bundles and register them as OSGi services. And while registering, we can give a property (say membershipScheme=wka) for that registration. This property will be same as what we give in axis2.xml for the membership scheme. When kernel tries to initialize the cluster, it will basically check on the available service registrations for the membership schemes and initialize the scheme given in the axis2.xml by checking the property. This way we can avoid any code changes in future. But we will need some initial code changes at kernel to support this. We are already following this approach for C5 clustering module to initailize the clustering agent : https://github.com/wso2/carbon-kernel/blob/master/modules/clustering/src/main/java/org/wso2/carbon/clustering/hazelcast/HazelcastClusteringAgent.java On Fri, Jul 10, 2015 at 10:42 AM, Afkham Azeez az...@wso2.com wrote: Yes, the membership scheme can be an OSGi service published with the unique schemeKey as a property. On Fri, Jul 10, 2015 at 9:54 AM, Imesh Gunaratne im...@wso2.com wrote: Hi, Currently in the Carbon Kernel, clustering membership schemes are statically defined [1]. As a result if it is needed to introduce a new membership scheme, we need to update the carbon core module. Shall we introduce an extension point here without breaking the existing membership scheme configuration? According to this approach we should be able to implement new membership schemes in separate bundles and specify them in the carbon.xml. [1] https://github.com/wso2/carbon4-kernel/blob/master/core/org.wso2.carbon.core/src/main/java/org/wso2/carbon/core/clustering/hazelcast/HazelcastClusteringAgent.java#L363 Thanks -- *Imesh Gunaratne* Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.gunaratne.org Lean . Enterprise . Middleware -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/* *email: **az...@wso2.com* az...@wso2.com * cell: +94 77 3320919 %2B94%2077%203320919blog: * *http://blog.afkham.org* http://blog.afkham.org *twitter: **http://twitter.com/afkham_azeez* http://twitter.com/afkham_azeez *linked-in: **http://lk.linkedin.com/in/afkhamazeez http://lk.linkedin.com/in/afkhamazeez* *Lean . Enterprise . Middleware* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Akila Ravihansa Perera Software Engineer, WSO2 Blog: http://ravihansa3000.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/* *email: **az...@wso2.com* az...@wso2.com * cell: +94 77 3320919 %2B94%2077%203320919blog: * *http://blog.afkham.org* http://blog.afkham.org *twitter: **http://twitter.com/afkham_azeez* http://twitter.com/afkham_azeez *linked-in: **http://lk.linkedin.com/in/afkhamazeez http://lk.linkedin.com/in/afkhamazeez* *Lean . Enterprise . Middleware
Re: [Architecture] [Carbon] [Kernel] Introducing a Clustering Membership Scheme Extension Point
Yes. Instead of giving the implementation class name in carbon.xml (we will have to use Class.forName to load the class), we can use OSGi declarative services approach here. What we can do is, we will have the implementation in different bundles and register them as OSGi services. And while registering, we can give a property (say membershipScheme=wka) for that registration. This property will be same as what we give in axis2.xml for the membership scheme. When kernel tries to initialize the cluster, it will basically check on the available service registrations for the membership schemes and initialize the scheme given in the axis2.xml by checking the property. This way we can avoid any code changes in future. But we will need some initial code changes at kernel to support this. We are already following this approach for C5 clustering module to initailize the clustering agent : https://github.com/wso2/carbon-kernel/blob/master/modules/clustering/src/main/java/org/wso2/carbon/clustering/hazelcast/HazelcastClusteringAgent.java On Fri, Jul 10, 2015 at 10:42 AM, Afkham Azeez az...@wso2.com wrote: Yes, the membership scheme can be an OSGi service published with the unique schemeKey as a property. On Fri, Jul 10, 2015 at 9:54 AM, Imesh Gunaratne im...@wso2.com wrote: Hi, Currently in the Carbon Kernel, clustering membership schemes are statically defined [1]. As a result if it is needed to introduce a new membership scheme, we need to update the carbon core module. Shall we introduce an extension point here without breaking the existing membership scheme configuration? According to this approach we should be able to implement new membership schemes in separate bundles and specify them in the carbon.xml. [1] https://github.com/wso2/carbon4-kernel/blob/master/core/org.wso2.carbon.core/src/main/java/org/wso2/carbon/core/clustering/hazelcast/HazelcastClusteringAgent.java#L363 Thanks -- *Imesh Gunaratne* Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.gunaratne.org Lean . Enterprise . Middleware -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/* *email: **az...@wso2.com* az...@wso2.com * cell: +94 77 3320919 %2B94%2077%203320919blog: * *http://blog.afkham.org* http://blog.afkham.org *twitter: **http://twitter.com/afkham_azeez* http://twitter.com/afkham_azeez *linked-in: **http://lk.linkedin.com/in/afkhamazeez http://lk.linkedin.com/in/afkhamazeez* *Lean . Enterprise . Middleware* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Custom AS specific WebApp configuration file for web applications
Hi Sameera, We need to show that this file is specific to web-applications deployed on AS and/or any other servers with webapp-mgt + CRE features right? So can we name it as wso2-web.xml ? This way it is generic across the platform. I agree with RuwanA on the fact that wso2as.xml will be a config file for the AS and will not give a sense that it is only used for web-applications. Examples http://geronimo.apache.org/GMOxDOC30/geronimo-webxml.html http://docs.oracle.com/cd/E26576_01/doc.312/e24929/dd-files.htm#GSDPG00078 https://docs.jboss.org/jbossweb/7.0.x/appdev/jbossweb.html Thanks, On Fri, Jul 3, 2015 at 3:36 PM, Sameera Jayasoma same...@wso2.com wrote: +1 for this. How about wso2as.xml? Thanks, Sameera. On Thu, Jul 2, 2015 at 7:14 PM, KasunG Gajasinghe kas...@wso2.com wrote: *Overview* Currently, there are several AS specific configuration options that are available for webapp developers when deploying webapps in AS. A set of identified configurations we have are as follows. 1. Configure the ClassLoader Runtime Environment and Classloading for web apps (such as Carbon/CXF/Tomcat/...) 2. Mark a JAX-RS webapp to be published as a Managed API for API-Everywhere story. 3. Enable Single Sign On support for webapps 4. Webapp SaaS configurations. 5. Enable WebApp Statistics publishing to DAS/BAM *Why?* Right now, we are using different mechanisms to configure these. Mostly, we ask webapp developers to put the configuration options as a context-param in the web.xml. We also have a custom AS specific configuration file called webapp-classloaading.xml to configure classloading runtimes. Using web.xml for this purpose is not a clean approach since web.xml it should only contain configurations that are portable across different application servers. For this purpose, Tomcat uses a custom context.xml to put Tomcat specific configurations. JBoss has jboss-web.xml. WebLogic has weblogic.xml, and so on.. *How?* The idea here is to generalize the current webapp-classloading.xml we already have into a configuration file where all the webapp related WSO2 AS configurations can be put. We could name this file as wso2as-web.xml or wso2as-application.xml. This is targeted for AS6 for immediate use with API-Everywhere feature. The implementation is fairly simple, and may be carried out as a fast-track training project. WDYT? Thanks, KasunG -- *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. email: kasung AT spamfree wso2.com linked-in: http://lk.linkedin.com/in/gajasinghe blog: http://kasunbg.org -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://blog.sameera.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Carbon] Migrate Carbon Platform to Log4j2
Hi Chathura, On Mon, Apr 20, 2015 at 9:27 AM, Chathura Priyankara chathu...@wso2.com wrote: Hi Kasun, Related to the Log4j upgrade in the Carbon platform there are following pros and cons of each method. 1. Using Log4j 1.2 bridge. Simplest way of converting log4j is to use the Log4j 1.2 bridge, but there are some limitations with this approach. Pros - Easy to upgrade need only to replace log4j 1.2 jar file with log4j-1.2-api.jar - Can use existing configuration. Cons - Cannot access methods of some classes such as Appenders. - Cannot programmatically configure Log4j - Cannot access create Logging events as it is internal to the Log4j core. 2. Native upgrade If we do a native upgrade we have to do some changes specially for the appenders and configurations. Pros - Support Appeners - log4j2 API and implementation is seperated. Cons - Need to convert all log4j configuratoins to XML Does this mean, log4j.properties file is no longer supported in 2.0? - Need to do modifications for all Appenders. What kind of modifications? Do we have API changes for Appenders as well? Also a general question. With the native upgrade, can other logging API's (SLF4j, JavaUtil, etc) be plugged in easily? Thanks. On Sun, Apr 19, 2015 at 12:28 PM, Kasun Gajasinghe kas...@wso2.com wrote: Hi Chathura, Can you also list down the pros and cons of each option? Thanks On Apr 16, 2015, at 2:59 PM, Sameera Jayasoma same...@wso2.com wrote: Hi Chathura, Lets do a native upgrade. Thanks, Sameera. On Thu, Apr 16, 2015 at 12:38 PM, Chathura Priyankara chathu...@wso2.com wrote: I'm currently working on migrating the Carbon platform to log4j 2.2 from 1.2.17. There are two ways of upgrading log4j version as follows. 1. Using the Log4j 1.2 bridge. 2. Native upgrade With the first option we cannot use Appenders. As we need Appender support I decided to select the second option. Appreciate any feedback about this approach. Thanks! Chathura. -- Chathura Priyankara Software Engineer | WSO2 Inc. Mobile : +94718795340 Blog : www.codeoncloud.blogspot.com -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://blog.sameera.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware -- Chathura Priyankara Software Engineer | WSO2 Inc. Mobile : +94718795340 Blog : www.codeoncloud.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [PPaaS] Modelling a Carbon Cluster with Stratos Composite Application Model (CAM)
Hi Imesh, I got a few questions on this. If I have two carbon clusters (AS cluster and ESB cluster), will there be two Stratos Composite Applications? Also I see two different terms being used here (Carbon Cluster and Stratos Cluster) What are the differences of them according to this model or are they refer the same? In the diagram, why we can have only one cartridge for Manager Group? What is Non WKA Cartridge? On Sun, Apr 26, 2015 at 12:53 PM, Imesh Gunaratne im...@wso2.com wrote: Hi, We had an initial team discussion on $subject for WSO2 PPaaS 4.1.0 M1 and this is how we thought we can model a Carbon cluster with Stratos Composite Application Model (CAM): *How it works:* - There would be a Stratos application defined for each Carbon server. - The startup dependencies would ask Stratos to start individual elements in the application tree in the given order. - Each cartridge would create a separate Stratos cluster (this is different from service cluster) and manage its minimum and maximum number of instances. - Scaling would happen according to Stratos clusters. - Each Stratos cluster would have a dedicated cluster host name and load balancer will be configured to use one cluster hostname for the worker cartridge group and another for the management cartridge group. - Clustering configuration (cluster discovery) will be automated by Stratos Cartridge Agent using an extension/plugin by using Metadata API similar to an approach in [1]. We will send a separate mail on this with details. *Features of This Model:* - WKA member management is handled by CAM - No need to implement logic in Stratos to handle it (in PPaaS 4.0.0 we had to customize Stratos to support this since CAM was not there). - Control the number of Management and Worker nodes needed with corresponding WKA and None WKA nodes using the Application definition. [1] https://coreos.com/docs/cluster-management/setup/cluster-discovery/ Thanks -- *Imesh Gunaratne* Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.gunaratne.org Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] How to release a milestone product pack ?
not a snapshot version so as a principle 'creation process of the pack' should be repeatable but if we allow SNAPSHOT dependencies inside product packs 'creation process of the pack' is not repeatable. This is not something standard, if we decided to go with this approach at least we should not call them as milestone packs instead SNAPSHOT packs (like nightly builds) e.g - G-Reg-5.0.0-SNAPSHOT-08-03-15 pack etc. *2.) Instead of SNAPSHOT dependencies, first release own dependencies with M-'X' (e.g - carbon-governance-4.4.0-M1 ) and then use these released versions within the milestone product pack. * Example - G-Reg 5.0.0-M3 pack can have carbon-governance-4.4.0-M2 and carbon-registry-4.3.2-M5 but NOT carbon-identity-4.3.1-M2 Pros - - Again relatively straightforward, we don't need to fork and maintain Maven release plug-in. - AFAIK adding post-fix to distinguish Milestone, Alpha, Beta versions is a standard practise [2] , [3] hence end users already aware not to use milestone versions in production. Cons - - There is a chance that other teams can use M-X packs in there milestone releases, we need a proper governance and disciplines not to do that (e.g - carbon-governance-4.4.0-M1 should be only use by G-Reg team within WSO2 other than special permissions) WDYT ? [1] - http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html [2] - Spring releases - http://repo1.maven.org/maven2/org/springframework/spring-core/ [3] - Hibernate releases - http://repo1.maven.org/maven2/org/hibernate/hibernate-search/ [4] - When I tied for above, build was stopped with following error. [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on project carbon-governance: Can't release project due to non released dependencies : [ERROR] org.wso2.carbon.registry:org.wso2.carbon.registry.admin.api:jar:4.3.1-SNAPSHOT:compile [ERROR] org.wso2.carbon.registry:org.wso2.carbon.registry.common:jar:4.3.1-SNAPSHOT:compile [ERROR] org.wso2.carbon.registry:org.wso2.carbon.registry.extensions:jar:4.3.1-SNAPSHOT:compile [ERROR] org.wso2.carbon.registry:org.wso2.carbon.registry.indexing:jar:4.3.1-SNAPSHOT:compile [ERROR] in project 'WSO2 Carbon - Governance' (org.wso2.carbon.governance:org.wso2.carbon.governance.api:bundle:4.3.1-SNAPSHOT) Thanks ! -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://blog.sameera.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware -- Blog: http://srinathsview.blogspot.com twitter:@srinath_perera Site: http://people.apache.org/~hemapani/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902 -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Milestone for GSS connector for ESB
Hi Naasheer, I think you are missing the point from Dushan here. You should explain the need for this connector. Even if you are doing an upgrade on an already existing connector, you should explain the reason behind the upgrade too. That way, the readers of this conversation will get a better understanding. Also in situations like this (upgrading an existing connector), it is better to point the references on the use cases (if they were sent out earlier). If you are trying to add more methods, then you should update the initial use case document and send it here. So consider these points even if you are planning to do this connector upgrade later. Thanks, Kishanthan. On Mon, Mar 2, 2015 at 5:30 PM, Naasheer Ali naashe...@wso2.com wrote: Hi, I'm not going to implement the connector now because I'm assigned to enable the OAuth support for the Jira Connector and It's urgent. I'll consider this when I develop the connector. Regards, -- *Naasheer Ali* | Associate Software Engineer WSO2, Inc |#20, Palm Grove, Colombo 03, Sri Lanka Email: naashe...@wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Fixing CApp story for Carbon 4.3.0
OK, lets go ahead with this. The initial plan is to write this for STS only so that IS can own this. But If ESB also need this, where are we going to maintain this? On Mon, Feb 16, 2015 at 11:53 AM, Johann Nallathamby joh...@wso2.com wrote: [Adding Godwin to the thread] IS team has already started working on this targeting the IS 5.1.0 release on Git based on carbon-kernel 4.3.0. Following are items we will be doing. 1. We will continue using the security wizard to apply STS policies and persist it to registry. 2. Previously the security policies as well as metadata were persisted in filesystem for axis2 services. Now we will be persisting them both in registry. In ESB the security policies only were stored in registry, so we will also try to reuse the same logic/location to store the security policies. 3. Recently we found that ESB also has a problem after removing the security wizard. In this new approach although security policies are applied in dev studio and persisted in registry we haven't thought about the role based access control which you get when doing through the security wizard. This got stored in the metafile. I was under the impression that this was also decided to be removed with these new changes. But looks like they still need it. So once we do this change they also will be able to use it. If you have any concerns please raise them now. Thanks. On Mon, Jul 7, 2014 at 3:15 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: On Sun, Jul 6, 2014 at 3:12 PM, Johann Nallathamby joh...@wso2.com wrote: Hi Kishanthan, On Tue, Jul 1, 2014 at 8:03 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: Hi All, We recently had a meeting on $subject. Our current story for CApp (Carbon Application) development approach is broken when including application of QoS for services. This was mainly due to the issues we faced with, - the file-based metadata persistence layer for services. - the possibility to change/apply QoS via mgt console. - clustering and deployment synchronization. To fix these, as the first step, we have removed the file based persistence layer from platform. This layer was mainly used to persist QoS related settings of the axis2services. This can be replaced by using services.xml file for each service. All types of axis2services (other than proxy-services) has support for services.xml currently. For proxy services, the application of some QoS (Ex: security) can be defined inline by referring the relevant policies from registry. We need a meeting to discuss about the following next steps. - How this will affect ESB (proxy-services) and how to fix those. - Removing the current way of applying QoS via mgt console and providing a different approach, which will not be part of the CApp development process. This will have serious impact on STS functionality of IS. STS is a specialised axis2 service, deployed from an OSGi bundle and shared across all tenants. The security policy used to secure the STS is within the scope of a tenant and is deployed as a service metafile like any other service. STS is unsecured by default. Tenant admins would secure the STS with preferred policy. Two reason why the above approach would not work for IS, 1. Securing STS is a admin functionality in my opinion. It is not a development time aspect. This may be not the case for other services. 2. Since STS is a shared service editing services.xml won't work. If we go with this new approach in platform, we need to do the following from IS side. 1. We need to continue using the security wizard UI to apply policies and modify the backend service to persist policy in either registry or Identity DB. 2. We need to modify the Security Deployment Interceptor which reads the security policy from filesystem, to read it from registry or database. Yes, this would be the option here. You can also use the same approach like how proxy services keep policy references for applied security scenarios with registry. @Sagara/KasunG How is AS team planning to handle this. Are you going to deprecate usage of security wizard UI and leave it to development time? Or are you having any other approach in mind? Thanks, Johann. Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Dev mailing list d...@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev -- Thanks Regards, *Johann Dilantha Nallathamby* Associate Technical Lead Product Lead of WSO2 Identity Server Integration Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+9476950* Blog - *http://nallaa.wordpress.com http
[Architecture] WSO2 Carbon Kernel 4.3.0 is Released !!!
Hi Folks, WSO2 Carbon team is pleased announce the release of the Carbon Kernel 4.3.0. *What is WSO2 Carbon* WSO2 Carbon redefines middleware by providing an integrated and componentized middleware platform that adapts to the specific needs of any enterprise IT project - on premise or in the cloud. 100% open source and standards-based, WSO2 Carbon enables developers to rapidly orchestrate business processes, compose applications and develop services using WSO2 Developer Studio and a broad range of business and technical services that integrate with legacy, packaged and SaaS applications. WSO2 Carbon kernel, the lean, modular, OSGi-based platform, is the base of the WSO2 Carbon platform. It is a composable server architecture which inherits modularity and dynamism from OSGi framework. WSO2 Carbon kernel can be considered as a framework for server development. All the WSO2 products are composed as a collection reusable components running on this kernel. These products/components inherits all the core services provided by Carbon kernel such as Registry/repository, User management, Transports, Caching, Clustering, Logging, Deployment related features. You can download the released distribution from the product home page : http://wso2.com/products/carbon/ *How to Contribute * - WSO2 Carbon Kernel code is hosted in GitHub. - The GIT repository is https://github.com/wso2/carbon4-kernel/ - Carbon 4.3.0 release *tag* is https://github.com/wso2/carbon4-kernel/releases/tag/4.3.0 *What's New In This Release* - Simplified logging story with pluggable log provider support. - Upgraded versions of Hazelcast, Log4j, BouncyCastle. - Improved Composite application support. *Key Features* - Composable Server Architecture - Provides a modular, light-weight, OSGi-based server development framework. - Carbon Application(CApp) deployment support. - Multi-Profile Support for Carbon Platform - This enable a single product to run on multiple modes/profiles. - Carbon + Tomcat JNDI Context - Provide ability to access both carbon level and tomcat level JNDI resources to applications using a single JNDI context. - Distributed Caching and Clustering functionality - Carbon kernel provides a distributed cache and clustering implementation which is based on Hazelcast- a group communication framework - Pluggable Transports Framework - This is based on Axis2 transports module. - Registry/Repository API- Provide core registry/repository API for component developers. - User Management API - Provides a basic user management API for component developers. - Logging - Carbon kernel supports both Java logging as well as Log4j. Logs from both these sources will be aggregated to a single output - Pluggable artifact deployer framework - Kernel can be extended to deploy any kind of artifacts such as Web services, Web apps, Business processes, Proxy services, User stores etc. - Deployment Synchronization - Provides synchronization of deployed artifacts across a product cluster. - Ghost Deployment - Provides a lazy loading mechanism for deployed artifacts/li - Multi-tenancy support - The roots of the multi-tenancy in Carbon platform lies in the Carbon kernel. This feature includes tenant level isolation as well as lazy loading of tenants. *Fixed Issues* - https://wso2.org/jira/issues/?filter=12100 *Known Issues* - https://wso2.org/jira/issues/?filter=12099 *Contact Us* WSO2 Carbon developers can be contacted via the mailing lists: - Carbon Developers List: d...@wso2.org - Carbon Architecture List: architecture@wso2.org *Reporting Issues* You can use the Carbon JIRA https://wso2.org/jira/browse/CARBON issue tracker to report issues, enhancements and feature requests for WSO2 Carbon. Thank for you interest in WSO2 Carbon Kernel. *--The WSO2 Carbon Team--* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Tomcat Session Replication Using Caching
/in/pubududissanayake* http://lk.linkedin.com/in/pubududissanayake Flickr : https://www.flickr.com/photos/pubudufx/ Twitter: https://twitter.com/GeekInAction -- Blog: http://srinathsview.blogspot.com twitter:@srinath_perera Site: http://people.apache.org/~hemapani/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902 -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/* *email: **az...@wso2.com* az...@wso2.com * cell: +94 77 3320919 %2B94%2077%203320919blog: * *http://blog.afkham.org* http://blog.afkham.org *twitter: **http://twitter.com/afkham_azeez* http://twitter.com/afkham_azeez *linked-in: **http://lk.linkedin.com/in/afkhamazeez http://lk.linkedin.com/in/afkhamazeez* *Lean . Enterprise . Middleware* -- *Pubudu Dissanayake* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware Mob: + 94 775 503 304 Blog: http://geekdetected.wordpress.com/ Linkedin: *http://lk.linkedin.com/in/pubududissanayake* http://lk.linkedin.com/in/pubududissanayake Flickr : https://www.flickr.com/photos/pubudufx/ Twitter: https://twitter.com/GeekInAction -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/* *email: **az...@wso2.com* az...@wso2.com * cell: +94 77 3320919 %2B94%2077%203320919blog: * *http://blog.afkham.org* http://blog.afkham.org *twitter: **http://twitter.com/afkham_azeez* http://twitter.com/afkham_azeez *linked-in: **http://lk.linkedin.com/in/afkhamazeez http://lk.linkedin.com/in/afkhamazeez* *Lean . Enterprise . Middleware* -- *Pubudu Dissanayake* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware Mob: + 94 775 503 304 Blog: http://geekdetected.wordpress.com/ Linkedin: *http://lk.linkedin.com/in/pubududissanayake* http://lk.linkedin.com/in/pubududissanayake Flickr : https://www.flickr.com/photos/pubudufx/ Twitter: https://twitter.com/GeekInAction -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Fixing CApp story for Carbon 4.3.0
On Sun, Jul 6, 2014 at 3:12 PM, Johann Nallathamby joh...@wso2.com wrote: Hi Kishanthan, On Tue, Jul 1, 2014 at 8:03 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: Hi All, We recently had a meeting on $subject. Our current story for CApp (Carbon Application) development approach is broken when including application of QoS for services. This was mainly due to the issues we faced with, - the file-based metadata persistence layer for services. - the possibility to change/apply QoS via mgt console. - clustering and deployment synchronization. To fix these, as the first step, we have removed the file based persistence layer from platform. This layer was mainly used to persist QoS related settings of the axis2services. This can be replaced by using services.xml file for each service. All types of axis2services (other than proxy-services) has support for services.xml currently. For proxy services, the application of some QoS (Ex: security) can be defined inline by referring the relevant policies from registry. We need a meeting to discuss about the following next steps. - How this will affect ESB (proxy-services) and how to fix those. - Removing the current way of applying QoS via mgt console and providing a different approach, which will not be part of the CApp development process. This will have serious impact on STS functionality of IS. STS is a specialised axis2 service, deployed from an OSGi bundle and shared across all tenants. The security policy used to secure the STS is within the scope of a tenant and is deployed as a service metafile like any other service. STS is unsecured by default. Tenant admins would secure the STS with preferred policy. Two reason why the above approach would not work for IS, 1. Securing STS is a admin functionality in my opinion. It is not a development time aspect. This may be not the case for other services. 2. Since STS is a shared service editing services.xml won't work. If we go with this new approach in platform, we need to do the following from IS side. 1. We need to continue using the security wizard UI to apply policies and modify the backend service to persist policy in either registry or Identity DB. 2. We need to modify the Security Deployment Interceptor which reads the security policy from filesystem, to read it from registry or database. Yes, this would be the option here. You can also use the same approach like how proxy services keep policy references for applied security scenarios with registry. @Sagara/KasunG How is AS team planning to handle this. Are you going to deprecate usage of security wizard UI and leave it to development time? Or are you having any other approach in mind? Thanks, Johann. Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Dev mailing list d...@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev -- Thanks Regards, *Johann Dilantha Nallathamby* Associate Technical Lead Product Lead of WSO2 Identity Server Integration Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+9476950* Blog - *http://nallaa.wordpress.com http://nallaa.wordpress.com* -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Fixing CApp story for Carbon 4.3.0
Hi All, We recently had a meeting on $subject. Our current story for CApp (Carbon Application) development approach is broken when including application of QoS for services. This was mainly due to the issues we faced with, - the file-based metadata persistence layer for services. - the possibility to change/apply QoS via mgt console. - clustering and deployment synchronization. To fix these, as the first step, we have removed the file based persistence layer from platform. This layer was mainly used to persist QoS related settings of the axis2services. This can be replaced by using services.xml file for each service. All types of axis2services (other than proxy-services) has support for services.xml currently. For proxy services, the application of some QoS (Ex: security) can be defined inline by referring the relevant policies from registry. We need a meeting to discuss about the following next steps. - How this will affect ESB (proxy-services) and how to fix those. - Removing the current way of applying QoS via mgt console and providing a different approach, which will not be part of the CApp development process. Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] OSGi Multi-Tenancy
On Mon, Jun 16, 2014 at 5:59 PM, Samisa Abeysinghe sam...@wso2.com wrote: So we have both of: - a tenant having specific bundles only available to that tenant - a bundle available for multiple tenants, where the respective tenant's use of the bundle is tenant aware Yes, but the latter will only be available for kernel region (core) bundles. am I right? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Fri, May 9, 2014 at 12:08 AM, Kishanthan Thangarajah kishant...@wso2.com wrote: On Thu, May 8, 2014 at 10:45 PM, Nuwan Bandara nu...@wso2.com wrote: Hi Kishanthan, A useful feature indeed, does this mean a tenant can install bundle for his own space ? Yes, each tenant will have a separate space (Region) and they can install bundles on to it. Other tenants will not be aware of this (bundle and service life-cycle events will be filtered) and cannot access those bundles (import package requirements will be filtered) . Also a bundle, with same symbolic name and version, can be installed on multiple tenant regions. This is handled using the BundleCollsionHook. Regards, /Nuwan On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka sur...@wso2.com wrote: HI Kishanthan, This is indeed a very helpful to have, one advantage I would see is we can let the tenants to have deployed their own Authenticators, UserStoreManagers and various other extensions without interfering the system. But how would be expose a Core service such as RealmService or RegistryService ? For example, each tenant will want to access their RealmService to load their configured user-store in their custom Authenticator. How would we make sure the RealmService would return only that tenant's RealmService or it's corresponding user store manager ? Thanks, -Suresh On Thu, May 8, 2014 at 2:45 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: This is one of the core areas of C5 kernel. In previous carbon versions, the multi-tenancy aspect was limited to run-time execution only. In there, we used the Axis2 Configuration Context model to achieve the multi-tenancy where each tenant got its own execution space during run-time. But the OSGi environment was not partitioned for tenants and was visible to all, where a bundle (the library and its packages) installed by a tenant was visible to other tenants as well. The idea here is to implement Multi-Tenancy at OSGi framework level also, so that each tenant gets its totally isolated run-time environment. We are planning to use OSGi Regions [1] concept to achieve this with the usage of OSGi framework hooks. A region is a grouping of bundles in an OSGi run-time, which is governed by controls when accessing resources (packages, services) from other regions. Each tenant gets its own region and there will be a separate Kernel region where the core bundles/packages/service resides and will be exposed to tenant regions. We can still limit/decide on what to expose from kernel region. Each tenant region will be isolated from each other. They will not see any events (related to bundle, service) or package visibility from other regions, but only see from it self and kernel. Below image is high level view of this concept. [image: Inline image 1] An overview of the framework hooks. *RegionResolverHook* - manages the package resolve process for requirements from bundles in regions. *RegionBundleFindHook* - manages/filters the BundleContext.getBundle lookups from region bundles. *RegionBundleEventHook* - manages/filters the bundle's life-cycle events for regions. *RegionBundleCollisionHook* - manages the duplicate bundle resolving in multiple regions. This will facilitate to have same bundles in different regions. *RegionServiceFindHook* and *RegionServiceEventHook* - manages/filters the service lookup and life-cycle events for regions. Thoughts suggestions are welcome. Thanks, Kishanthan. [1] http://wiki.eclipse.org/Virgo/Concepts#Regions -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Suresh Attanayake Senior Software Engineer; WSO2 Inc. http://wso2.com/ Blog : http://sureshatt.blogspot.com/ Web : http://www.ssoarcade.com/ Facebook : https://www.facebook.com/IdentityWorld Twitter : https://twitter.com/sureshatt LinkedIn : http://lk.linkedin.com/in/sureshatt Mobile : +94755012060 Mobile : +016166171172 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin
[Architecture] [C5] OSGi Multi-Tenancy
This is one of the core areas of C5 kernel. In previous carbon versions, the multi-tenancy aspect was limited to run-time execution only. In there, we used the Axis2 Configuration Context model to achieve the multi-tenancy where each tenant got its own execution space during run-time. But the OSGi environment was not partitioned for tenants and was visible to all, where a bundle (the library and its packages) installed by a tenant was visible to other tenants as well. The idea here is to implement Multi-Tenancy at OSGi framework level also, so that each tenant gets its totally isolated run-time environment. We are planning to use OSGi Regions [1] concept to achieve this with the usage of OSGi framework hooks. A region is a grouping of bundles in an OSGi run-time, which is governed by controls when accessing resources (packages, services) from other regions. Each tenant gets its own region and there will be a separate Kernel region where the core bundles/packages/service resides and will be exposed to tenant regions. We can still limit/decide on what to expose from kernel region. Each tenant region will be isolated from each other. They will not see any events (related to bundle, service) or package visibility from other regions, but only see from it self and kernel. Below image is high level view of this concept. [image: Inline image 1] An overview of the framework hooks. *RegionResolverHook* - manages the package resolve process for requirements from bundles in regions. *RegionBundleFindHook* - manages/filters the BundleContext.getBundle lookups from region bundles. *RegionBundleEventHook* - manages/filters the bundle's life-cycle events for regions. *RegionBundleCollisionHook* - manages the duplicate bundle resolving in multiple regions. This will facilitate to have same bundles in different regions. *RegionServiceFindHook* and *RegionServiceEventHook* - manages/filters the service lookup and life-cycle events for regions. Thoughts suggestions are welcome. Thanks, Kishanthan. [1] http://wiki.eclipse.org/Virgo/Concepts#Regions -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] OSGi Multi-Tenancy
On Thu, May 8, 2014 at 10:45 PM, Nuwan Bandara nu...@wso2.com wrote: Hi Kishanthan, A useful feature indeed, does this mean a tenant can install bundle for his own space ? Yes, each tenant will have a separate space (Region) and they can install bundles on to it. Other tenants will not be aware of this (bundle and service life-cycle events will be filtered) and cannot access those bundles (import package requirements will be filtered) . Also a bundle, with same symbolic name and version, can be installed on multiple tenant regions. This is handled using the BundleCollsionHook. Regards, /Nuwan On Thu, May 8, 2014 at 5:35 AM, Suresh Attanayaka sur...@wso2.com wrote: HI Kishanthan, This is indeed a very helpful to have, one advantage I would see is we can let the tenants to have deployed their own Authenticators, UserStoreManagers and various other extensions without interfering the system. But how would be expose a Core service such as RealmService or RegistryService ? For example, each tenant will want to access their RealmService to load their configured user-store in their custom Authenticator. How would we make sure the RealmService would return only that tenant's RealmService or it's corresponding user store manager ? Thanks, -Suresh On Thu, May 8, 2014 at 2:45 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: This is one of the core areas of C5 kernel. In previous carbon versions, the multi-tenancy aspect was limited to run-time execution only. In there, we used the Axis2 Configuration Context model to achieve the multi-tenancy where each tenant got its own execution space during run-time. But the OSGi environment was not partitioned for tenants and was visible to all, where a bundle (the library and its packages) installed by a tenant was visible to other tenants as well. The idea here is to implement Multi-Tenancy at OSGi framework level also, so that each tenant gets its totally isolated run-time environment. We are planning to use OSGi Regions [1] concept to achieve this with the usage of OSGi framework hooks. A region is a grouping of bundles in an OSGi run-time, which is governed by controls when accessing resources (packages, services) from other regions. Each tenant gets its own region and there will be a separate Kernel region where the core bundles/packages/service resides and will be exposed to tenant regions. We can still limit/decide on what to expose from kernel region. Each tenant region will be isolated from each other. They will not see any events (related to bundle, service) or package visibility from other regions, but only see from it self and kernel. Below image is high level view of this concept. [image: Inline image 1] An overview of the framework hooks. *RegionResolverHook* - manages the package resolve process for requirements from bundles in regions. *RegionBundleFindHook* - manages/filters the BundleContext.getBundle lookups from region bundles. *RegionBundleEventHook* - manages/filters the bundle's life-cycle events for regions. *RegionBundleCollisionHook* - manages the duplicate bundle resolving in multiple regions. This will facilitate to have same bundles in different regions. *RegionServiceFindHook* and *RegionServiceEventHook* - manages/filters the service lookup and life-cycle events for regions. Thoughts suggestions are welcome. Thanks, Kishanthan. [1] http://wiki.eclipse.org/Virgo/Concepts#Regions -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Suresh Attanayake Senior Software Engineer; WSO2 Inc. http://wso2.com/ Blog : http://sureshatt.blogspot.com/ Web : http://www.ssoarcade.com/ Facebook : https://www.facebook.com/IdentityWorld Twitter : https://twitter.com/sureshatt LinkedIn : http://lk.linkedin.com/in/sureshatt Mobile : +94755012060 Mobile : +016166171172 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Thanks Regards,* * Nuwan Bandara | Senior Technical Lead - Solutions Architecture, WSO2 Inc.+1 812.606.7390 %2B1%20812.606.7390 | +1 650.745.4499 Ext 4210 %2B1%20650.745.4499%20Ext%204210 | http://nuwanbando.com http://nuwanbando.com * http://www.nuwanbando.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc
Re: [Architecture] [C5] Solution for Patching C5 Servers
Mobile: +94 71 9040362 | Work: +94 112145345 Email: ar...@wso2.com | Web: www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *S. Suhothayan* Technical Lead Team Lead of WSO2 Complex Event Processor *WSO2 Inc. *http://wso2.com * http://wso2.com/* lean . enterprise . middleware *cell: (+94) 779 756 757 %28%2B94%29%20779%20756%20757 | blog: http://suhothayan.blogspot.com/ http://suhothayan.blogspot.com/ twitter: http://twitter.com/suhothayan http://twitter.com/suhothayan | linked-in: http://lk.linkedin.com/in/suhothayan http://lk.linkedin.com/in/suhothayan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [C5] Using annotations for declarative services compoenets
Hi All,
C5 project is now following the standardized annotation based model with
declarative service components, which is specified in the OSGi compendium
specification [1]. These standard annotation related classes are available
with the following dependency.
dependency
groupIdorg.eclipse.osgi/groupId
artifactIdorg.eclipse.osgi.services/artifactId
/dependency
Apache Felix scr.ds-annotations and maven-scr-plugin [2] can be used to
process the annotated class and generate the component descriptors (the
meta files).
Here is an example usage.
@*Component*(
name = org.wso2.carbon.kernel.internal.CommandProvider,
immediate = true
)
public class CarbonKernelCommandProvider implements CommandProvider {
private CarbonRuntime carbonRuntime;
private ServiceRegistrationCommandProvider serviceRegistration;
@*Activate*
public void registerCommandProvider(BundleContext bundleContext) {
serviceRegistration =
bundleContext.registerService(CommandProvider.class, this, null);
}
@*Deactivate*
public void unregisterCommandProvider(BundleContext bundleContext) {
serviceRegistration.unregister();
}
@*Reference*(
name = carbon.runtime.service,
service = CarbonRuntime.class,
cardinality = ReferenceCardinality.MANDATORY,
policy = ReferencePolicy.DYNAMIC,
unbind = unsetCarbonRuntime
)
public void setCarbonRuntime(CarbonRuntime carbonRuntime) {
this.carbonRuntime = carbonRuntime;
}
public void unsetCarbonRuntime(CarbonRuntime carbonRuntime) {
this.carbonRuntime = null;
}
}
This will be documented for development with C5.
Thanks,
Kishanthan.
[1] http://www.osgi.org/download/r5/osgi.cmpn-5.0.0.pdf
[2]
https://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-maven-scr-plugin-use.html
https://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-maven-scr-plugin-use.html
--
*Kishanthan Thangarajah*
Senior Software Engineer,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com*
Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Shipping Streaming JSON Builder/Formatter by Default in Kernel axis2.xml
mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Anjana Fernando* Technical Lead WSO2 Inc. | http://wso2.com lean . enterprise . middleware -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] WSO2 TS 1.1.0 Alpha Released!
Are we planning on releasing product documentation as-well? On Thu, Mar 13, 2014 at 7:59 AM, Chanika Geeganage chan...@wso2.com wrote: *WSO2 Task Server 1.1.0 - Alpha Released!* The Alpha pack is available at: http://svn.wso2.org/repos/wso2/people/chanika/TS_1.1.0_Alpha/ Following are the key features. Key Features - Working as a dedicated task provider for other carbon servers. - Executing any web task from an application as the task provider remotely. We welcome your feedback on this release of TS. Thanks -- Best Regards.. Chanika Geeganage Software Engineer WSO2, Inc.; http://wso2.com ___ Dev mailing list d...@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Jetty integration with carbon kernel
On Tue, Mar 11, 2014 at 12:04 AM, Sagara Gunathunga sag...@wso2.com wrote: On Mon, Mar 10, 2014 at 10:11 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: We have done $subject which can be used for servlet transport in C5 kernel [1]. The embedded jetty instance uses a default jetty.xml configuration file located at $CARBON_HOME/repository/conf/jetty/jetty.xml. The main advantage of jetty is that it is OSGi friendly [2]. It can also expose the OSGi HttpSevice for servlet registrations, etc. We are thinking of using this for the UI framework of carbon. Other servlet container can also be plugged in (Eg: Tomcat with AS) using the plugable run-time concept, but they will use different ports to avoid +1 please see my comments below. 1.) Have we define the scope of Jetty integration within Carbon ? if not we need to define what are the supported Jetty features and what are the features not supported based on our needs. To make it clear we are not trying to make Tomcat kind of integration here instead we need basic servlet support for Admine console, we don't need to support web socket , JSP 2.2 , EL 2.2 etc :) But if we don't define the scope users may confuse and can be treated as a weakness and there is a high chance to compare Carbon-Jetty with Carbon-Tomcat. The current plan is to use this for UI framework, and AdminServices framework (JAX-RS services, which we need the servlet support). We don't need to support all the features of jetty at kernel level. The main purpose of this to remove the dependency of tomcat at kernel level. So that products like AS can independently do changes (like upgrading tomcat). Integration and usage of Tomcat will be same like before (like Apps hosting in AS), but the only change is that UI and AdminServices framework will use Jetty instead. 2.) What are the dependencies required for Jetty and how we going to keep them ? within the Jetty bundle or import from other bundles ? If 2nd one is the approach we need to be very careful and should follow best practises like OSGi versioning etc from day-0. I would prefer if Carbon not exporting dependencies like servlet-api , xml-api etc so that each Carbon product can have control on these dependencies. We could solve these type of issues with proper package imports/exports with versions. 3.) It would be better to avoid publishing Jeety related details on user guides, here Jetty is the underline framework we used but what Carbon user wants is technology to right admin UIs and admin services that's what we need to cover on user guides. One good example is Jetty support on GAE. +1. Thanks ! collisions. Thanks, Kishanthan. [1] https://wso2.org/jira/browse/CARBON-14716 [2] http://wiki.eclipse.org/Jetty/Feature/Jetty_OSGi -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [C5] Jetty integration with carbon kernel
We have done $subject which can be used for servlet transport in C5 kernel [1]. The embedded jetty instance uses a default jetty.xml configuration file located at $CARBON_HOME/repository/conf/jetty/jetty.xml. The main advantage of jetty is that it is OSGi friendly [2]. It can also expose the OSGi HttpSevice for servlet registrations, etc. We are thinking of using this for the UI framework of carbon. Other servlet container can also be plugged in (Eg: Tomcat with AS) using the plugable run-time concept, but they will use different ports to avoid collisions. Thanks, Kishanthan. [1] https://wso2.org/jira/browse/CARBON-14716 [2] http://wiki.eclipse.org/Jetty/Feature/Jetty_OSGi -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] cluster configuration (cluster.xml)
, Isuru Perera isu...@wso2.comwrote:
Shall we use camel case naming convention as we had in axis2.xml?
Also the properties seem to have a specific elements. Does this
mean that the new clustering API should look at element name to
identify
the property?
No, it looks at all the children under properties, and exposes them
in the config object model. You can have any random element there.
Okay. I understand. Then the XSD will allow to have any element.
IMO, name/value properties are much better as we had in axis2.xml.
Makes it easier to validate XML also. I think, it's a must for having
an
XSD, especially when the time comes for Developer Studio integration.
On Tue, Feb 4, 2014 at 12:06 PM, Kishanthan Thangarajah
kishant...@wso2.com wrote:
Below is the example cluster.xml (initial version) we came up,
which is used with the default hazelcast based clustering
implementation.
We can add any new elements to this and the configuration will get
build
with those. The clustering impl will look-up and use those
elements/properties from clustering config as needed. We can merge the
hazelcast related properties also with this file (which we now have
separately in a properties file).
Its up to the clustering impl to read this and initialize the
cluster, based on the given value for the agent. For example, there
can
be multiple clustering impl bundles (hazelcast, tribes, etc), but at
run-time, only one will get initialized. Other bundles will be in
active
state, but they will not initialize.
*clustering agent=hazelcast enable=false*
*!--The membership scheme used in this setup--*
*membership-schememulticast/membership-scheme*
*!--The clustering domain--*
*domainwso2.carbon.domain/domain*
*!--The host name or IP address of this member-- *
*local-member-host127.0.0.1/local-member-host*
*!--The TCP port used by this member--*
*local-member-port4000/local-member-port*
*!--**Properties specific to this member**--*
*properties*
*
backend-server-urlhttps://${hostName}:${httpsPort}/services//backend-server-url*
*
mgt-console-urlhttps://${hostName}:${httpsPort}//mgt-console-url*
*/properties*
*!-- multicast membership scheme related properties--*
*multicast*
*address228.0.0.4/address*
*port45564/port*
*ttl100/ttl*
*timeout60/timeout*
*/multicast*
*!-- wka membership scheme related properties--*
*wka*
*!-- The list of static or well-known members--*
*members*
*member*
*host-name127.0.0.1/host-name*
*port4000/port*
*/member*
*/members*
*/wka*
*/clustering*
Thoughts?
Thanks,
Kishanthan.
--
*Kishanthan Thangarajah*
Senior Software Engineer,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com
http://kishanthan.wordpress.com*
Twitter - *http://twitter.com/kishanthan
http://twitter.com/kishanthan*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
about.me/chrishantha
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* http://www.apache.org/*
*email: **az...@wso2.com* az...@wso2.com
* cell: +94 77 3320919 %2B94%2077%203320919 blog: *
*http://blog.afkham.org* http://blog.afkham.org
*twitter:
**http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez
* linked-in: **http://lk.linkedin.com/in/afkhamazeez
http://lk.linkedin.com/in/afkhamazeez*
*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
Isuru Perera
Senior Software Engineer | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
about.me/chrishantha
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
With regards,
*Manu*ranga Perera.
phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* http://www.apache.org/*
*email: **az...@wso2.com* az...@wso2.com
* cell: +94 77 3320919 %2B94
Re: [Architecture] [C5] Clustering SPI
As per feedback and suggestions, the following are the defined methods for ClusteringAgent. Also we have tried to remove the dependency on the configuration-context model from clustering impl, as there was no need/use for that. With these, we now have a basic working clustering implementation, supporting multicast and wka membership schemes based on hazelcast. We will next arrange the design and code review sessions. *ClusteringAgent* /** * Initialize the agent which will initialize this node, and join the cluster */ void *init*() throws *ClusterInitializationException*; /** * Shutdown the agent which will remove this node from cluster */ void *shutdown*(); /** * Send a message to all members in the cluster */ void *sendMessage*(ClusterMessage msg) throws *MessageSendFailedException*; /** * Send a message to a set of specific members in the cluster */ void *sendMessage*(ClusterMessage msg, ListClusterMember members) throws *MessageSendFailedException*; On Mon, Jan 20, 2014 at 2:49 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: On Sun, Jan 19, 2014 at 3:22 PM, Afkham Azeez az...@wso2.com wrote: On Sun, Jan 19, 2014 at 3:11 PM, Isuru Perera isu...@wso2.com wrote: How about following change? s/ClusteringFault/ClusteringException Yes, no more Fault in exception names. Those exception names were inspired by SOAP. In addition, instead of ClusteringException, we need to have some specific types; e.g. ClusterInitializationException, MessageFailedException etc. +1. Thanks, Kishanthan. On Sun, Jan 19, 2014 at 11:40 AM, Kishanthan Thangarajah kishant...@wso2.com wrote: Clustering SPI provides the ability to plug-in different clustering implementation to carbon. By default, carbon will ship hazel-cast based clustering impl. There will be a separate file (cluster.xml) for cluster configuration. The SPI will contain the following main interfaces. *ClusteringAgent* - is responsible for initializing and managing this node in the cluster. *MembershipScheme* - a representation of a membership scheme such as multicast or well-known address (wka) used in the cluster. A high-level view can be as follows [image: Inline image 1] When the cluster agent is successfully initialized, it will also register the Cluster Service (being discussed at [C5] Clustering API). The Cluster Service will use the clustering agent underneath at implementation level for its required operations. Based on previous experiences, we have defined the following methods for clustering agent and membership scheme for now. Based on the final outcome of this discussion, they may get changed. *ClusteringAgent* /** * Initialize the agent which will initialize this node, and join the cluster */ void *init*() throws ClusteringFault; /** * Shutdown the agent which will remove this node from cluster */ void *shutdown*() throws ClusteringFault; /** * Set carbon configuration context to this agent to be used in the clustering impl */ void *setConfigurationContext*(CarbonConfigurationContext configurationContext); /** * Get the list of static members */ ListClusterMember *getStaticMembers*(); /** * Get the number of members alive. */ int *getAliveMemberCount*(); /** * Send a message to all members in the cluster */ ListClusteringCommand *sendMessage*(ClusterMessage msg, boolean isSync) throws ClusteringFault; /** * Send a message to a set of specific members in the cluster */ ListClusteringCommand *sendMessage*(ClusterMessage msg, ListClusterMember members, boolean isSync) throws ClusteringFault; *MembershipScheme* void *init*() throws ClusteringFault; void *joinGroup*() throws ClusteringFault; Thoughts? Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Isuru Perera Senior Software Engineer | WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware about.me/chrishantha ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/* *email: **az...@wso2.com* az...@wso2.com * cell: +94 77 3320919 %2B94%2077
Re: [Architecture] [C5] Clustering SPI
Hi Chris, [Forwarding to architecture@] We thought of having some meaningful names for the exceptions. So came up with this, which include the Failed part. I was looking into some references on exception thrown when sending messages, before coming up with these names. For example [1]. WDYT? Thanks, Kishanthan. [1] http://docs.oracle.com/javaee/6/api/javax/mail/SendFailedException.html On Tue, Feb 4, 2014 at 11:41 AM, chris snow chsnow...@gmail.com wrote: hi Kishanthan, sorry for the dumb (and late) question, but is the extra word 'Failed' necessary? Instead of *MessageSendFailedException *why not just *MessageSendException*? On Tue, Feb 4, 2014 at 5:19 AM, Kishanthan Thangarajah kishant...@wso2.com wrote: As per feedback and suggestions, the following are the defined methods for ClusteringAgent. Also we have tried to remove the dependency on the configuration-context model from clustering impl, as there was no need/use for that. With these, we now have a basic working clustering implementation, supporting multicast and wka membership schemes based on hazelcast. We will next arrange the design and code review sessions. *ClusteringAgent* /** * Initialize the agent which will initialize this node, and join the cluster */ void *init*() throws *ClusterInitializationException*; /** * Shutdown the agent which will remove this node from cluster */ void *shutdown*(); /** * Send a message to all members in the cluster */ void *sendMessage*(ClusterMessage msg) throws *MessageSendFailedException*; /** * Send a message to a set of specific members in the cluster */ void *sendMessage*(ClusterMessage msg, ListClusterMember members) throws *MessageSendFailedException*; On Mon, Jan 20, 2014 at 2:49 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: On Sun, Jan 19, 2014 at 3:22 PM, Afkham Azeez az...@wso2.com wrote: On Sun, Jan 19, 2014 at 3:11 PM, Isuru Perera isu...@wso2.com wrote: How about following change? s/ClusteringFault/ClusteringException Yes, no more Fault in exception names. Those exception names were inspired by SOAP. In addition, instead of ClusteringException, we need to have some specific types; e.g. ClusterInitializationException, MessageFailedException etc. +1. Thanks, Kishanthan. On Sun, Jan 19, 2014 at 11:40 AM, Kishanthan Thangarajah kishant...@wso2.com wrote: Clustering SPI provides the ability to plug-in different clustering implementation to carbon. By default, carbon will ship hazel-cast based clustering impl. There will be a separate file (cluster.xml) for cluster configuration. The SPI will contain the following main interfaces. *ClusteringAgent* - is responsible for initializing and managing this node in the cluster. *MembershipScheme* - a representation of a membership scheme such as multicast or well-known address (wka) used in the cluster. A high-level view can be as follows [image: Inline image 1] When the cluster agent is successfully initialized, it will also register the Cluster Service (being discussed at [C5] Clustering API). The Cluster Service will use the clustering agent underneath at implementation level for its required operations. Based on previous experiences, we have defined the following methods for clustering agent and membership scheme for now. Based on the final outcome of this discussion, they may get changed. *ClusteringAgent* /** * Initialize the agent which will initialize this node, and join the cluster */ void *init*() throws ClusteringFault; /** * Shutdown the agent which will remove this node from cluster */ void *shutdown*() throws ClusteringFault; /** * Set carbon configuration context to this agent to be used in the clustering impl */ void *setConfigurationContext*(CarbonConfigurationContext configurationContext); /** * Get the list of static members */ ListClusterMember *getStaticMembers*(); /** * Get the number of members alive. */ int *getAliveMemberCount*(); /** * Send a message to all members in the cluster */ ListClusteringCommand *sendMessage*(ClusterMessage msg, boolean isSync) throws ClusteringFault; /** * Send a message to a set of specific members in the cluster */ ListClusteringCommand *sendMessage*(ClusterMessage msg, ListClusterMember members, boolean isSync) throws ClusteringFault; *MembershipScheme* void *init*() throws ClusteringFault; void *joinGroup*() throws ClusteringFault; Thoughts? Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http
[Architecture] [C5] cluster configuration (cluster.xml)
Below is the example cluster.xml (initial version) we came up, which is
used with the default hazelcast based clustering implementation. We can add
any new elements to this and the configuration will get build with those.
The clustering impl will look-up and use those elements/properties from
clustering config as needed. We can merge the hazelcast related properties
also with this file (which we now have separately in a properties file).
Its up to the clustering impl to read this and initialize the cluster,
based on the given value for the agent. For example, there can be
multiple clustering impl bundles (hazelcast, tribes, etc), but at run-time,
only one will get initialized. Other bundles will be in active state, but
they will not initialize.
*clustering agent=hazelcast enable=false*
*!--The membership scheme used in this setup--*
*membership-schememulticast/membership-scheme*
*!--The clustering domain--*
*domainwso2.carbon.domain/domain*
*!--The host name or IP address of this member-- *
*local-member-host127.0.0.1/local-member-host*
*!--The TCP port used by this member--*
*local-member-port4000/local-member-port*
*!--**Properties specific to this member**--*
*properties*
*
backend-server-urlhttps://${hostName}:${httpsPort}/services//backend-server-url*
*
mgt-console-urlhttps://${hostName}:${httpsPort}//mgt-console-url*
*/properties*
*!-- multicast membership scheme related properties--*
*multicast*
*address228.0.0.4/address*
*port45564/port*
*ttl100/ttl*
*timeout60/timeout*
*/multicast*
*!-- wka membership scheme related properties--*
*wka*
*!-- The list of static or well-known members--*
*members*
*member*
*host-name127.0.0.1/host-name*
*port4000/port*
*/member*
*/members*
*/wka*
*/clustering*
Thoughts?
Thanks,
Kishanthan.
--
*Kishanthan Thangarajah*
Senior Software Engineer,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware
Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com*
Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [C5] WSO2 Carbon Kernel 5.0.0 - M2 Release
Hi All, We are pleased to inform you that the second milestone release for Carbon Kernel 5.0.0 is now available for download [1]. This milestone includes the first development release of carbon based deployment framework [2]. *Fixed Issues* https://wso2.org/jira/browse/CARBON-14605?filter=11710 *How to contribute?* C5 code base is available in GitHup [3]. You can clone this repository and do a maven build from the root. We also encourage to use the GitHub pull requests based approach for contributing to the code base. If you have any suggestions or interested in C5 discussions, please do so via d...@wso2.org or architecture@wso2.org mailing lists. You can report any issues or bugs via the issue tracking system [4]. Thanks, Carbon Team [1] https://svn.wso2.org/repos/wso2/people/kishanthan/carbon-5.0.0/milestone-2/wso2carbon-kernel-5.0.0-SNAPSHOT.zip [2] http://docs.wso2.org/display/Carbon500/Deployment+Engine [3] https://github.com/wso2/carbon-kernel [4] https://wso2.org/jira/browse/CARBON https://github.com/wso2/carbon-kernel-- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Fwd: How can we patch Jaggery Apps?
If I think along this view point, a clean way to handle this is to register a carbon server extension, which gets executed during the server start-up. And this extension should handle the patch applying strategy for apps (or anything we need do before the server starts). This is how we handle the normal patch applying process also. A carbon server extension is a launch extension, which gets executed before the OSGi run-time is started (eg: dropins bundle installer, patch installer, etc). But currently, without requiring code changes, it is not possible to register a new server extension. There should be a way (may be via configuration file) to register new server extensions with server. But this feature is lacking at kernel level now. May be we can consider this requirement for next kernel release (4.3.x). This also leads to some other questions as-well. i.e we have to a patching process which is common and consistence for all kind of artifacts we plan to support. On Sun, Jan 26, 2014 at 2:22 PM, Senaka Fernando sen...@wso2.com wrote: Hi all, IMHO, anything shipped in the binary pack that we release has a potential of eventually being patched. Some files may be more frequently patched and some might never be. But, given that each file can potentially be patched the patching model needs to take everything into consideration. So, though we started off discussing jaggery apps, we should be looking at the broader picture (as Ruchira explained). But, it is not easy as replacing files. Let me explain why. - There are configuration files where users may introduce changes. These files should either be excluded from the patching model or we need to capture it in a way such that automatic replacements do not happen. Now, again, its not easy as giving repository/conf special treatment, because configurations for Jaggery apps reside within them. So, we need a story that works for everything. - Patching DB scripts won't help a bit, because the actual DBs should also be migrated if something is done, so they cannot be a part of the patching model. - When we patch, we also need to be looking @ maintaining backups. We have a model to backup the OSGi bundles (i.e. patch). For Jaggery Apps, we need something equivalent. - Also, just like jaggery apps, we also have other things like webapps (JAX-RS and JAX-WS services deployed on CXF), humantasks (ex:- WorkList in G-Reg), etc. If we are trying to find a solution for Jaggery Apps so must we find a solution for these two, or the patching model will keep changing release after release. So, IMHO, its best to start with something focusing on the complete story, find what problems that approach presents and find solutions for those rather than picking individual problems and solving them locally. Also, Kishanthan, we simply cannot categorize anything to be user-level and exclude it. As I said before, we are liable to have a strategy to patch anything that we ship. And, if each individual type of artifact is patched in its own way, the life of the server administrator becomes very complicated. So, we must try to make things work in a similar way as much as possible. Thanks, Senaka. On Sun, Jan 26, 2014 at 10:20 AM, Kishanthan Thangarajah kishant...@wso2.com wrote: On Sat, Jan 25, 2014 at 4:53 PM, Sameera Medagammaddegedara samee...@wso2.com wrote: Hello Everyone, *Problem* - As it stands ,if a Jaggery application needs to be updated the user must manually copy the required files - This introduces a number of problems - If several files need to be changed it will become a chore - A user may forget to copy one or more files - It departs from the normal way in which patches are applied to other WSO2 products IMO, these are user level issues. From a server POV, a jaggery app is considered as a deployment artifact. So it can follow the process of normal artifact update. But the main point here on why do we need to patch jaggery apps is that, with some product releases, we are also releasing jaggery apps as part of it. So we need a way to patch those released apps. - The files that could be included in a patch to a Jaggery file could include (but is not limited ) to the following; 1. JAG files 2. JS files 3. Jaggery Modules ( These will be JS files) 4. Images and CSS files 5. JSON files *Suggestion* - Package the files to be replaced in a zip format - All Jaggery App patches could be placed in the repository/components/patches/jaggeryapps similar to the way existing patches are applied - *Structure of the patch* - Please refer to attached image - The files to be updated would need to be organized according to structure of the app or module to be patched - Before the application is deployed the archive is extracted
Re: [Architecture] [Dev] Proposed code repository restructuring move to GitHub
On Tue, Jan 21, 2014 at 12:51 PM, Shariq Muhammed sha...@wso2.com wrote: On Tue, Jan 21, 2014 at 12:38 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: Yes, we don't need to separately say service-stubs, it should be under the components level as just another component. Initially we extracted out the service stubs because it doesn't change frequently. So we can reduce the build time because we don't need to do wsdl2java in each build cycle. Looks like we are going to add it back? The situation is different than earlier. If we look at the current proposed approach, we will not be building the components, which, in most case, are not directly related to what we work on. They will get built separately and deployed to the maven repo and the other components which are depending on will be using them. This way the build time will be greatly reduced. On Tue, Jan 21, 2014 at 12:30 PM, Eranda Sooriyabandara era...@wso2.comwrote: Hi Kicha, There will be no service stubs directory it will be a additional component in the same level as BE + FE components. thanks Eranda On Tue, Jan 21, 2014 at 11:41 AM, Kishanthan Thangarajah kishant...@wso2.com wrote: Hi Eranda, Where have you put the service-stubs related to governance component? It should come under the same repo as carbon-component-governance. On Tue, Jan 21, 2014 at 12:29 AM, Eranda Sooriyabandara era...@wso2.com wrote: Hi All, As a PoC I just completed the carbon-component-governance. Please find it in [1] and let me know your comments and suggestions. Please keep in mind that this is not in a buildable state since other components need to build before this. thanks Eranda [1] https://github.com/wso2/carbon-component-governance On Fri, Jan 17, 2014 at 9:26 PM, Afkham Azeez az...@wso2.com wrote: [Sorry for the very long mail. I want to document all that I had in mind the stuff we discussed. I would recommend all devs to take some time to read this] I would like to summarize he discussion we had a couple of days back. *The Problems* The problems we are trying to solve are as follows: 1. Trunk branches structures being completely different 2. Branches containing directories with version numbers 3. It is impossible to move to GitHub with the current structure because of #2 4. It is very easy to break the build by changing already released code. The room for human error is high. 5. Bamboo builds are eternally broken because the build fails at some point Bamboo cannot continue any further 6. When we branch, the trunk quickly becomes obsolete, and remains in that broken state until the next major platform release. 7. Everybody has to build all components/features, even if those are not related to their products 8. Fixed versions in branches instead of using SNAPSHOT versions. This makes it impossible to upload build artifacts to Maven/Nexus repos. This leads to #7. 9. Impossible to integrate code quality tools such as EraInsight because of #5 *Proposed solution* We have come up with the following solution after much deliberation thought. Rationale: We started looking at other open source projects out there. We took Axis2 as an example. Axis2 had many dependencies including Axiom, XmlSchema, Woden, WSS4J etc. Those 3rd party dependencies were also developed by some Axis2 contributors, but we never branched all of those together and brought them into the same code branch. We used to start what we used to call a release train, where the upstream code would have to be released first before the downstream code such as Axis2 Synapse could be released. This way, we never had any of the problems outlined above. If you look at the WSO2 product releases, again, the scenario is not that much different from the Axis2/Synapse releases. Components features are simply dependencies of the products. In order to get product releases out, we first need releases of those dependencies (components/features). So the proposal is to identify the top level components/features, and first release that code before doing product releases. Each of those components will have a GitHub repo. All active development will be done on the main branch of those components, and will be branched when they are close to the release. Instead of granting commit rights to all, we could only allow the primary developers of those components to commit, and others can send pull requests, which will be merged in by the primary owners after reviewing. These component teams could even have an internal Git repo or clone, and commit to that, run all tests, and when they are satisfied that the code is in a good state to be merged into the main branch, they can send a pull request merge the changes. We would run Bamboo which would build the components several times a day deploy them to the Nexus repo. That way, you would not have to build code that is not directly related to what you
Re: [Architecture] Proposed code repository restructuring move to GitHub
will use the Maven release plugin to create releases upload them to the Maven repo. *Implications to WSO2 code developers* 1. Life becomes easier because you don't have to spend a lot of time building unrelated stuff 2. General development would happen in the main branch. 3. Close to a release, branches would be cut. 4. Once release branches are cut, fixes would be done in the main branch, and pull requests would be sent to the branch merged in. This will be easy because we no longer have the trunk branch structure being different. *Implications to users* Users will not see any difference in the components features because we are not changing packages or binary structure. In fact, we would have a P2 repo with compatible features which all work together. Senaka, Isuruwan Harshana have already started working on a PoC. Thoughts welcome. Those who were in these discussions, please add anything I may have missed. -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/* *email: **az...@wso2.com* az...@wso2.com * cell: +94 77 3320919 %2B94%2077%203320919 blog: * *http://blog.afkham.org* http://blog.afkham.org *twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez * linked-in: **http://lk.linkedin.com/in/afkhamazeez http://lk.linkedin.com/in/afkhamazeez* *Lean . Enterprise . Middleware* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Eranda Sooriyabandara*Senior Software Engineer; Integration Technologies Team; WSO2 Inc.; http://wso2.com Lean . Enterprise . Middleware E-mail: eranda AT wso2.com Mobile: +94 716 472 816 Linked-In: http://www.linkedin.com/in/erandasooriyabandara Blog: http://emsooriyabandara.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Proposed code repository restructuring move to GitHub
Yes, we don't need to separately say service-stubs, it should be under the components level as just another component. On Tue, Jan 21, 2014 at 12:30 PM, Eranda Sooriyabandara era...@wso2.comwrote: Hi Kicha, There will be no service stubs directory it will be a additional component in the same level as BE + FE components. thanks Eranda On Tue, Jan 21, 2014 at 11:41 AM, Kishanthan Thangarajah kishant...@wso2.com wrote: Hi Eranda, Where have you put the service-stubs related to governance component? It should come under the same repo as carbon-component-governance. On Tue, Jan 21, 2014 at 12:29 AM, Eranda Sooriyabandara era...@wso2.comwrote: Hi All, As a PoC I just completed the carbon-component-governance. Please find it in [1] and let me know your comments and suggestions. Please keep in mind that this is not in a buildable state since other components need to build before this. thanks Eranda [1] https://github.com/wso2/carbon-component-governance On Fri, Jan 17, 2014 at 9:26 PM, Afkham Azeez az...@wso2.com wrote: [Sorry for the very long mail. I want to document all that I had in mind the stuff we discussed. I would recommend all devs to take some time to read this] I would like to summarize he discussion we had a couple of days back. *The Problems* The problems we are trying to solve are as follows: 1. Trunk branches structures being completely different 2. Branches containing directories with version numbers 3. It is impossible to move to GitHub with the current structure because of #2 4. It is very easy to break the build by changing already released code. The room for human error is high. 5. Bamboo builds are eternally broken because the build fails at some point Bamboo cannot continue any further 6. When we branch, the trunk quickly becomes obsolete, and remains in that broken state until the next major platform release. 7. Everybody has to build all components/features, even if those are not related to their products 8. Fixed versions in branches instead of using SNAPSHOT versions. This makes it impossible to upload build artifacts to Maven/Nexus repos. This leads to #7. 9. Impossible to integrate code quality tools such as EraInsight because of #5 *Proposed solution* We have come up with the following solution after much deliberation thought. Rationale: We started looking at other open source projects out there. We took Axis2 as an example. Axis2 had many dependencies including Axiom, XmlSchema, Woden, WSS4J etc. Those 3rd party dependencies were also developed by some Axis2 contributors, but we never branched all of those together and brought them into the same code branch. We used to start what we used to call a release train, where the upstream code would have to be released first before the downstream code such as Axis2 Synapse could be released. This way, we never had any of the problems outlined above. If you look at the WSO2 product releases, again, the scenario is not that much different from the Axis2/Synapse releases. Components features are simply dependencies of the products. In order to get product releases out, we first need releases of those dependencies (components/features). So the proposal is to identify the top level components/features, and first release that code before doing product releases. Each of those components will have a GitHub repo. All active development will be done on the main branch of those components, and will be branched when they are close to the release. Instead of granting commit rights to all, we could only allow the primary developers of those components to commit, and others can send pull requests, which will be merged in by the primary owners after reviewing. These component teams could even have an internal Git repo or clone, and commit to that, run all tests, and when they are satisfied that the code is in a good state to be merged into the main branch, they can send a pull request merge the changes. We would run Bamboo which would build the components several times a day deploy them to the Nexus repo. That way, you would not have to build code that is not directly related to what you are working on, which would save 100s of valuable dev hours. In the majority of the cases, the P2 features correspond to one or more related components. So we would keep the feature close to the component. There are some cases where these components features belong in the product itself. AppFactory components are a good example. Products will also have their own GitHub repos. We will have separate GitHub repos for platform integration tests. Products such as API Manager may opt to have the API Management feature in the product itself. We would have a separate P2-repo GitHub repo which would build deploy the compatible set of P2 features. We will have Bamboo plans at multiple levels; components, products, platform, p2-repo and so on. We
[Architecture] [C5] Clustering SPI
Clustering SPI provides the ability to plug-in different clustering implementation to carbon. By default, carbon will ship hazel-cast based clustering impl. There will be a separate file (cluster.xml) for cluster configuration. The SPI will contain the following main interfaces. *ClusteringAgent* - is responsible for initializing and managing this node in the cluster. *MembershipScheme* - a representation of a membership scheme such as multicast or well-known address (wka) used in the cluster. A high-level view can be as follows [image: Inline image 1] When the cluster agent is successfully initialized, it will also register the Cluster Service (being discussed at [C5] Clustering API). The Cluster Service will use the clustering agent underneath at implementation level for its required operations. Based on previous experiences, we have defined the following methods for clustering agent and membership scheme for now. Based on the final outcome of this discussion, they may get changed. *ClusteringAgent* /** * Initialize the agent which will initialize this node, and join the cluster */ void *init*() throws ClusteringFault; /** * Shutdown the agent which will remove this node from cluster */ void *shutdown*() throws ClusteringFault; /** * Set carbon configuration context to this agent to be used in the clustering impl */ void *setConfigurationContext*(CarbonConfigurationContext configurationContext); /** * Get the list of static members */ ListClusterMember *getStaticMembers*(); /** * Get the number of members alive. */ int *getAliveMemberCount*(); /** * Send a message to all members in the cluster */ ListClusteringCommand *sendMessage*(ClusterMessage msg, boolean isSync) throws ClusteringFault; /** * Send a message to a set of specific members in the cluster */ ListClusteringCommand *sendMessage*(ClusterMessage msg, ListClusterMember members, boolean isSync) throws ClusteringFault; *MembershipScheme* void *init*() throws ClusteringFault; void *joinGroup*() throws ClusteringFault; Thoughts? Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* C5 - Clustering.png___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [C5] Clustering API
This thread is to discuss about $subject. Our current clustering API's contains stuffs that are mixture of both user level and developer level API. We will have to separate out these with the clear definition. For clustering API (user level), we will have the following methods. We can discuss clustering SPI's on a separate thread. *void sendMessage(ClusterMessage clusterMessage);* *void sendMessage(ClusterMessage clusterMessage, ListClusterMember members);* *ListClusterMember getMembers();* *void addMembershipListener(MembershipListener membershipListener);* *void removeMembershipListener(MembershipListener membershipListener);* In here we also thought of having MembershipListener (A listener which gets notified when changes occur in Membership) related API at user level. This will be useful when user wants to get some event notification when the current membership changes. Adding a new MembershipListener will follow the white board pattern. The API for MembershipListener *void memberAdded(MembershipEvent event);* *void memberRemoved(MembershipEvent event);* MembershipEvent will be of two types (member added or removed). Thoughts? Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [C5] Maintaining orbit as an external project
Our current approach of having third party dependencies as OSGi bundles is to make them into an orbit project. The release of them happen with the kernel or platform release. Because of this, currently when building carbon from source, we first have to build orbit. But this is not needed if we maintain orbit as an external project (may be in git-hub) and use one of the following. 1. Use SNAPSHOT repo approach. The developer who creates a new orbit project will have to deploy the snapshot version of it to the repo. The official release of those will happen on its own way. It can align either with a kernel release or platform release (major or patch releases). 2. Releasing the newly created orbit project immediately after creating it. This is possible because we don't normally do any changes to it (pom) afterwards. This also has to be done by the developer (after all the testing). The downside of this is we may end up with multiple versions for a projects. But this will be minimal. In both cases above, the components requiring those orbit dependencies will have to update to those released/snapshot versions. The orbit projects for forked dependencies will follow the same approach as earlier. Suggestions and thoughts are welcome. Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Logging framework
On Tue, Dec 17, 2013 at 11:30 AM, Chamil Jeewantha cha...@wso2.com wrote: Hi Sameera, What are the benefits of having logging function as an OSGI service, Can't we simply make logging available in the plain java way across all the bundles? We will not expose logging as an OSGI service. It will be the same as what we have now (in C4). The bundles (or any other applications) can use any of the logging API which is supported by the logging framework. Those log events will be captured by the framework and sent to the backend, which is handled by log4j. The change we have incorporated into C5 is that, instead using our own logging framework, we will use PaxLogging. There is another concept in OSGI called, LogService [1], which is a simple general purpose logging service for OSGI platform. It does not provide all the functionality which other logging APIs provide. This was not explicitly supported earlier in carbon, but the current C5 logging framework do support this. Thanks, Kishanthan. [1] http://www.osgi.org/javadoc/r4v42/org/osgi/service/log/LogService.html Chamil On Mon, Dec 16, 2013 at 12:02 PM, Sameera Jayasoma same...@wso2.comwrote: We've implemented the logging functionality in C5 is using Pax logging. Logging is enabled when the Pax logging bundle is activated. But I faced two major issues with Pax logging that we need to fix immediately. 1) Carbon launcher component logs info and debug levels before launching the OSGi framework. These log messages never make their way to the wso2carbon.log file. Because the Pax bundle only enables the logging services once the Pax bundle is activated by the OSGi framework. Therefore OSGi framework has to be up and running to get the logging functionality working, otherwise we loose all log messages logged before the OSGi framework starts. [1] 2) OSGi bundles face a similar problem. it is related to the bundle starting order. There are two sub issues here. (i) If a bundle becomes active and start logging before the Pax bundle becomes active, then we again loose those log messages. (ii) OSGi frameworks stops each and every bundle before deactivating itself. If the Pax bundle is stopped, then logging service becomes unavailable. Say a bundle wants to log during the server stop and if the Pax bundle is stopped before this bundle, we loose all the logs messages. [2] If we are going ahead with Pax, then we need to solve these problems ASAP. Thanks, Sameera. [1] CARBON-14612 - Logging component does not capture the logs messages logged before Carbon launcher starts OSGi frameworkhttps://wso2.org/jira/browse/CARBON-14612 [2] CARBON-14613 - Log messages are lost if they ares logged before the Pax bundle is started. https://wso2.org/jira/browse/CARBON-14613 On Fri, Nov 29, 2013 at 2:47 PM, Afkham Azeez az...@wso2.com wrote: I would suggest going with PAX logging, Azeez On Thu, Nov 28, 2013 at 12:37 PM, Kishanthan Thangarajah kishant...@wso2.com wrote: I'm bringing up this thread to discuss on the logging backend and logging framework in C5. Our current logging framework uses log4j as the logging backend and support a set of logging APIs (commons-logging, slf4j, java-logging, log4j logger). We currently don't support OSGI LogService. But we need to decide on whether do we need to support this as there were some decision made earlier not to support? This framework is serving well so far, but if we have to support other logging APIs then we will have to write them. *Alternatives* 1. Log4j2 [1] (logging backend only) The next generation of log4j. It is still at the beta stage in release. This looks promising as the numbers of this is way ahead of its predecessor [2]. 2. Pax logging [3] (complete framework) This framework uses a similar concept as ours. It uses log4j as the backend and support a whole set of logging APIs such as commons-logging API, log4J-logger API, jdk-logging, avalon-logger API, knopflerfish-log and tomcat-juli. It also has support for OSGI LogService API. So far we found that Pax logging has the support for all required logging APIs including the support for OSGI LogService. Other projects mostly have written their own way to handle different logging APIs like ours. Thoughts and ideas are welcome ! Thanks, Kishanthan. [1] http://logging.apache.org/log4j/2.x/ [2] http://www.javacodegeeks.com/2013/07/log4j-2-performance-close-to-insane.html [3] https://ops4j1.jira.com/wiki/display/paxlogging/Pax+Logging -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http
[Architecture] C5 Kernel codebase is now moved to GitHub
Hi Folks, We have moved the current C5 kernel code-base to GitHub. The URL for this project is : https://github.com/wso2/carbon-kernel The current project structure will get changed as we are in the process of restructuring. Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] Carbon 5 (C5) - The next generation of WSO2 Carbon Platform.
On Wed, Nov 27, 2013 at 6:14 PM, Vijayaratha Vijayasingam rat...@wso2.comwrote: On 27 November 2013 17:44, Sameera Jayasoma same...@wso2.com wrote: *What is C5?* Carbon 5 will be the next generation of WSO2 Carbon Platform. *Why C5?* The existing Carbon platform has served as a modular middleware platform for more than 5 years now. We've built many different products, solutions based on this platform. All the previous major releases of Carbon were sharing the same high level architecture, even though we've changed certain things time to time. Base architecture of the Carbon is modeled using the Apache Axis2's kernel architecture. Apache Axis2 is Web service engine. But it also has introduced a rich extensible server framework with a configuration and runtime model, deployment engine, clustering API and a implementation, etc. We extended this architecture and built a OSGI based modular server development framework called Carbon Kernel. It is tightly coupled with Apache Axis2. But now Apache Axis2 is becoming a dead project. We don't see enough active development on the trunk. Therefore we thought of getting rid of this tight coupling to Apache Axis2. Carbon kernel has gained weight over the time. There are many unwanted modules there. When there are more modules, the rate of patching or the rate of doing patch releases increases. This is why we had to release many patch releases of Carbon kernel in the past. This can become a maintenance nightmare for developers as well as for the users. We need to minimize Carbon kernel releases. The other reason for C5 is to make Carbon kernel a general purpose OSGi runtime, specialized in hosting servers. We will implement the bare minimal features required for server developers in the Carbon kernel. Our primary goal of C5 is to re-architect the Carbon platform from the ground up with the latest technologies and patterns to overcome the existing architectural limitations as well as to get rid of the dependencies to the legacy technologies like Apache Axis2. Does this mean , C5 will move away from Axis2 and use another SOAP engine? As explained above, axis2 was used for different purposes at carbon kernel. One of them is to handle AdminServices. In C5, to handle AdminServices concept, we will move towards JAX-RS based approach. C5 kernel will be independent from any run-times (yes, Axis2 is a run-time). You can use it build your own server. The server you build on will have to plug in the run-time (Axis2 , CXF, etc) it requires. We need to build a next generation middleware platform that will last for the next 10 years. *When can you expect C5?* We have already started working on C5 with a dedicated team of 5 members for three to four months. We are planning to complete the bare minimal components of C5 by March, 2014. Once we get to this stage, our products teams can start migrating their components to this new architecture. I will share the detailed milestone plan shortly. Thanks, Sameera. -- Sameera Jayasoma, Architect, WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- -Ratha mobile: (+94)755906608 ___ Dev mailing list d...@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [C5] Logging framework
I'm bringing up this thread to discuss on the logging backend and logging framework in C5. Our current logging framework uses log4j as the logging backend and support a set of logging APIs (commons-logging, slf4j, java-logging, log4j logger). We currently don't support OSGI LogService. But we need to decide on whether do we need to support this as there were some decision made earlier not to support? This framework is serving well so far, but if we have to support other logging APIs then we will have to write them. *Alternatives* 1. Log4j2 [1] (logging backend only) The next generation of log4j. It is still at the beta stage in release. This looks promising as the numbers of this is way ahead of its predecessor [2]. 2. Pax logging [3] (complete framework) This framework uses a similar concept as ours. It uses log4j as the backend and support a whole set of logging APIs such as commons-logging API, log4J-logger API, jdk-logging, avalon-logger API, knopflerfish-log and tomcat-juli. It also has support for OSGI LogService API. So far we found that Pax logging has the support for all required logging APIs including the support for OSGI LogService. Other projects mostly have written their own way to handle different logging APIs like ours. Thoughts and ideas are welcome ! Thanks, Kishanthan. [1] http://logging.apache.org/log4j/2.x/ [2] http://www.javacodegeeks.com/2013/07/log4j-2-performance-close-to-insane.html [3] https://ops4j1.jira.com/wiki/display/paxlogging/Pax+Logging -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [C5] Adding deployers to deployment engine
On Wed, Oct 9, 2013 at 12:04 PM, Afkham Azeez az...@wso2.com wrote: No, this is violating whiteboard pattern. The way to do it is, each deployer should implement an interface, and an implementation of that interface should be registered as an OSGi service. You should not have a CarbonDeploymentService OSGi service. Using whiteboard pattern, handle the dynamic environment where deployers would get registered when their deployer services are registered and unregistered when those bundles stop or the services are unregistered. Yes. That is what we have to do. I totally missed that :). Azeez On Wed, Oct 9, 2013 at 7:35 AM, Kishanthan Thangarajah kishant...@wso2.com wrote: Hi All, We need to think about $subject and come up with a proper way. Currently (pre C5) we can add deployers to the depolyment engine (which is Axis2Deployment Engine) using the following different ways. 1. Reading from component.xml using bundle listener and adding to axisConfig (widely used) 2. Defining in axis2.xml (this is not widely used in carbon). 3. Using the ConfigurationContext OSGI service and calling the axisConfig From C5, we will be removing the axis2 dependency from kernel, which also provided the deployment part, and will have our own way to handle deployment. This will be, say CarbonDeploymentEngine. So we are thinking of having simple and a clean way for $subject with carbon deployment engine. How about using an OSGI service for this, say CarbonDeploymentService, which provide some simple API methods (addDeployer, getDeployer etc)? There will be a Deployer interface, which the users will implement and write their own deployers, and they will call this service to add them to the deployment engine. Thoughts? Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan* -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * http://www.apache.org/** email: **az...@wso2.com* az...@wso2.com* cell: +94 77 3320919 blog: **http://blog.afkham.org* http://blog.afkham.org* twitter: **http://twitter.com/afkham_azeez*http://twitter.com/afkham_azeez * linked-in: **http://lk.linkedin.com/in/afkhamazeez* * * *Lean . Enterprise . Middleware* -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [C5] Adding deployers to deployment engine
Hi All, We need to think about $subject and come up with a proper way. Currently (pre C5) we can add deployers to the depolyment engine (which is Axis2Deployment Engine) using the following different ways. 1. Reading from component.xml using bundle listener and adding to axisConfig (widely used) 2. Defining in axis2.xml (this is not widely used in carbon). 3. Using the ConfigurationContext OSGI service and calling the axisConfig From C5, we will be removing the axis2 dependency from kernel, which also provided the deployment part, and will have our own way to handle deployment. This will be, say CarbonDeploymentEngine. So we are thinking of having simple and a clean way for $subject with carbon deployment engine. How about using an OSGI service for this, say CarbonDeploymentService, which provide some simple API methods (addDeployer, getDeployer etc)? There will be a Deployer interface, which the users will implement and write their own deployers, and they will call this service to add them to the deployment engine. Thoughts? Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Merged web application and Jax-WS/RS application directories
I'm sure this wouldn't cause any issues, but did we test this with worker/manager setup (with Dep Synch)? On Sun, Jul 7, 2013 at 10:19 AM, Supun Malinga sup...@wso2.com wrote: Hi devs, I have done $subject in trunk. If you are using repository/deployment/server/jaxwebapps directory, please switch to repository/deployment/server/webapps directory. Let us know if you need more info./help.. Please talk to AS team if you have any further concerns.. https://wso2.org/jira/browse/WSAS-1288 thanks, -- Supun Malinga, Senior Software Engineer, WSO2 Inc. http://wso2.com http://wso2.org email - sup...@wso2.com sup...@wso2.com mobile - 071 56 91 321 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Merging JAX-WS/RS and WebApp, deployers and deployment directories
We currently have a separate UI component for Jax* webapps. What will happen to that? Are we going to keep it? On Wed, May 22, 2013 at 1:04 PM, Supun Malinga sup...@wso2.com wrote: Hi All, Currently we have two deployment directories for deploying Jax-WS/RS app and tomcat WebApps. In this model we use two different deployers to deploy both types of apps. Since we have moved cxf dependencies out if osgi space and introduced new class-loading mechanisms for webapps, there is no real advantage of keeping these things separate now. In addition to that we get the advantage of being able to provide webapp exploding support for jax-rs/ws apps with this approach. However for this to work seamlessly with the existing logic for separately identifying the webapp type, we need to identify within the deployer, which is duable. I will update with the further progress on this. Please shout if there are concerns. thanks, -- Supun Malinga, ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Generalizing Git Based Deployment Synchronizer
On Fri, May 3, 2013 at 9:51 PM, Isuru Haththotuwa isu...@wso2.com wrote: The modified interface abstraction to get repository information, create or add repositories will be as follows: Interface name: RepositoryManager Methods: void addRepository (); - add a repository created by a tenant. void provisionRepository (); - create a repository on behalf of a tenant. RepositoryInformation getReopsitoryInformation (); - retrieve repository information such as url, user name and password, etc. Doesn't this include the tenant-id as input? or how to differentiate the repositories among tenants? On Sun, Apr 28, 2013 at 10:58 PM, Isuru Haththotuwa isu...@wso2.comwrote: The proposed interface for RepositoryInformationProvider tentatively would have a single method: public RepositoryInformation getRepositoryInformation(int tenantId); RepositoryInformation instance would hold data of the remote repository for the tenant, such as url, username, password, etc. On Wed, Apr 24, 2013 at 4:13 PM, Pradeep Fernando prad...@wso2.comwrote: Hi Isuru, On Wed, Apr 24, 2013 at 12:39 PM, Isuru Haththotuwa isu...@wso2.comwrote: The main limitations with the current architecture related to generalizing the implementation are identified as follows: 1. The dependency on S2 based environment to get the information about the repositories for the tenants: A potential solution would be to abstract out the implementation for a repository information provider so that it can manage both the single repository (standard deployment), multiple repository (S2 / specialized deployment) and any other scenarios. 2. Usage of deployment synchronization messages in standard and S2 deployments: In the current implementation, the ADC will send a GroupManagementCommand (a deployment synchronization message) when there are updates in the repository. The standard Deployment Synchronization message has been programatically disabled from the git based deployment synchronizer component, which is an incorrect thing to do. It was decided to hold a separate discussion on this to come up with a proper architecture for usage of deployment synchronization messages in different environments (standard and S2 environment). please go ahead and schedule. 3. Supporting ghost deployment of artifacts: Svn based deployment synchronizer supports ghost deployment of artifacts through svn partial checkouts. Git doesn't support partial checkouts, so this is a potential problem. There may be workarounds available, need to research on this. On Fri, Apr 19, 2013 at 6:21 PM, Isuru Haththotuwa isu...@wso2.comwrote: The Git based Deployment Synchronizer developed for Stratos 2 supports Git repositories per tenant, which is a significant difference from other Deployment Synchronizers (SVN depsync, etc). Therefore Git Depsync has to query a service to obtain the git repository URLs and the credentials for the repositories for each tenant at run time. In the SVN depsync, a single repo is used and it's defined in the carbon.xml. Because of this, it is not possible to use the Git Depsync to in a normal worker manager separation, in a similar way as SVN Depsync. To use it in the worker manager separated setup, we can either create another component which is similar to SVN depsync which uses a single repository, or else generalize this implementation so that it can be used in both S2 scenario (with repos per tenant) and in normal worker manager separation (single repo). Thoughts? ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Thanks and Regards, Isuru H. -- Thanks and Regards, Isuru H. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kishanthan Thangarajah* Software Engineer, Development Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com* Twitter - *http://twitter.com/kishanthan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
