Re: [Architecture] [Dev] [VOTE] Release WSO2 Enterprise Integrator 6.2.0 RC2
analytics and publish statistics. >>>>>- Analyse ESB statistics with analytics profile. >>>>>- Deploy and test sample BPEL, BPMN, and human-task process. >>>>>- BPMN explorer for basic functionalities. >>>>>- Humanatsk explorer with task actions. >>>>>- Add users, roles, and Tenants. >>>>>- View, add and delete registry resources. >>>>>- Check the readme files and release notes. >>>>> >>>>> >>>>> [+] Stable - go ahead and release >>>>> >>>>> Regards, >>>>> Waruna >>>>> >>>>> On Sat, Mar 17, 2018 at 2:50 AM, Himasha Guruge <himas...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> We are pleased to announce the second release candidate of WSO2 >>>>>> Enterprise Integrator 6.2.0. >>>>>> >>>>>> *Known issues*: https://github.com/wso2/product-ei/issues >>>>>> >>>>>> *Source and binary distribution files*: >>>>>> <https://github.com/wso2/product-ei/releases/tag/v6.2.0-rc1>*https://github.com/wso2/product-ei/releases/tag/v6.2.0-rc2 >>>>>> <https://github.com/wso2/product-ei/releases/tag/v6.2.0-rc2>* >>>>>> >>>>>> *The tag to be voted upon*: >>>>>> *https://github.com/wso2/product-ei/tree/v6.2.0-rc2 >>>>>> <https://github.com/wso2/product-ei/tree/v6.2.0-rc2>* >>>>>> >>>>>> Please vote as follows: >>>>>> [+] Stable - go ahead and release >>>>>> [-] Broken - do not release (explain why) >>>>>> >>>>>> ~The WSO2 Integration Team~ >>>>>> >>>>>> >>>>>> -- >>>>>> Himasha Guruge >>>>>> Senior Software Engineer >>>>>> WS*O2* *Inc.* >>>>>> Mobile: +94 777459299 <+94%2077%20745%209299> >>>>>> himas...@wso2.com >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Waruna Lakshitha Jayaweera >>>>> Senior Software Engineer >>>>> WSO2 Inc; http://wso2.com >>>>> phone: +94713255198 <+94%2071%20325%205198> >>>>> http://waruapz.blogspot.com/ >>>>> >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> ___ >>>> Dev mailing list >>>> d...@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Heshitha Hettihewa >>> *Software Engineer* >>> Mobile : +94716866386 >>> <%2B94%20%280%29%20773%20451194> >>> heshit...@wso2.com >>> >>> ___ >>> Dev mailing list >>> d...@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Himasha Guruge >> Senior Software Engineer >> WS*O2* *Inc.* >> Mobile: +94 777459299 <+94%2077%20745%209299> >> himas...@wso2.com >> >> ___ >> Dev mailing list >> d...@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Prabushi Samarakoon* > Software Engineer > Mobile: +94715434580 <+94%2071%20543%204580> > Email: prabus...@wso2.com > > ___ > Dev mailing list > d...@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Niranjan Karunanandham* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Location for .m2 repo of a daemon maven
Hi Kasun, On Fri, Nov 10, 2017 at 6:01 PM, Kasun Siyambalapitiya <kasu...@wso2.com> wrote: > Hi all, > > I am currently working on a `go lang` application which will be used to > provision a server (written in `Java`) by building a given `pom.xml` file. > Since `Java` is required for running the server, we can assume that the > running system is already having `Java` installed, but it could or could > not have `maven` installed. > > So without installing `maven` or setting `M2_HOME` in `$PATH` variable of > the running system, the `go` application is written in such a way that it > uses a exploded `maven` distribution in a specific location for performing > the build. > > Although `maven` build runs as a daemon process in the above scenario, it > creates the `.m2` repo at the current user's home by default. What will be > best option for location of `.m2` repo out of following, > >1. Place `.m2` repo at the place where the application runs (can be >configured using `settings.xml`) >2. Place `.m2` repo at the current user's home. > > It would be better to go with option 2 where we use .m2 repo configured by the user. The reason for this, there is only one m2 repo in the user's machine. If the user wants to change the m2 location use by your application, then IMO there should be a configuration to set this. > Your thoughts on the above are highly appreciated. > > Thanks > > -- > *Regards,* > > *Kasun Siyambalapitiya* > *Software Engineer* > WSO2 Inc. - http://wso2.com/ > lean . enterprise . middleware > Tel : 0715523466 > E mail : kasu...@wso2.com > Blog: https://medium.com/@kasunsiyambalapitiya > <https://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
Re: [Architecture] Same feature with different versions in different runtimes
Hi Kasun,
Have we created a git issue for the carbon-maven-plugins with regard to not
able to download two versions of the same feature to create a p2-repo?
Regards,
Nira
On 8 Sep 2017 5:13 a.m., "Kasun Siyambalapitiya" <kasu...@wso2.com> wrote:
> Hi Dilan and all,
>
> Pardon me for the late reply. Yes, I agree with your point due to the fact
> that different feature versions including slight or major differences in
> their implementation has been released as compatible features for WSO2
> Carbon 4.4.x (Wilkes) [1] products,
>
> For example,
>
>
>1.
> org.wso2.carbon.identity.application.authentication.framework.server_4.5.6.jar
>/ org.wso2.carbon.identity.application.authentication.framewor
>k.server_5.7.5.jar
>2. org.wso2.carbon.directory.service.mgr.server_4.5.6.jar /
>org.wso2.carbon.directory.service.mgr.server_5.7.5.jar
>3. rg.wso2.carbon.forum.server_2.0.0.jar / org.wso2.carbon.forum.server
>_6.1.66.jar
>4. org.wso2.carbon.identity.core.server_4.5.5.jar
>/ org.wso2.carbon.identity.core.server_5.7.5.jar
>5. org.wso2.carbon.identity.core.ui_4.5.5.jar
>/ org.wso2.carbon.identity.core.ui_5.7.5.jar
>
> Since all the jars mentioned above have major implementational changes
> which are not backward compatible (as indicated by the major version no
> change) there is a huge possibility of having a functional inconsistency in
> the system if multiple versions of the same feature are used in different
> runtimes. For example the format of data inserted and queried out from db
> from previous version may differ from the how it is done in the latest
> version leaving to inconsistencies in DB. IMO I think either we should
> restrict to one version of a certain feature or allow up to it's next major
> version. WDYT?
>
>
> [1] http://product-dist.wso2.com/p2/carbon/releases/wilkes/features/
>
> Thanks.
>
> On Fri, Aug 18, 2017 at 8:39 AM, Dilan Udara Ariyaratne <dil...@wso2.com>
> wrote:
>
>> Hi Kasun and All,
>>
>> Let me raise a different, but fundamental concern to this issue. Please
>> correct me if I am wrong.
>>
>> It's perfectly valid to have the same feature on different run-times (or
>> profiles) of a product, but if that same feature appears in "different
>> versions",
>> meaning, with slight or major differences of their implementations, at
>> different run-times of the product, wouldn't that open up any possibilities
>> of functional inconsistencies or even failures to the overall system ?
>>
>> Thanks,
>> Dilan.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Thu, Aug 17, 2017 at 8:19 PM, Kasun Siyambalapitiya <kasu...@wso2.com>
>> wrote:
>>
>>> Hi Niranjan,
>>>
>>> When generating the p2-repository using `carbon-maven-plugin version
>>> 3.x` this issue arises due to the fact that it resolves dependencies for
>>> each given feature with the dependencies we defined in the pom itself (note
>>> that the effective pom is used for the resolving). Since maven picks only
>>> one version of a given dependency due the use of `nearest in the dependency
>>> tree` strategy, a p2-repo with multiple versions of the same feature can
>>> not be created by using the current `carbon-maven-plugin version 3.1.3`.
>>>
>>> But in the case of `carbon-maven-plugin version 1.5.x` this is possible
>>> as the dependencies of each feature is defined in a string form as below
>>>
>>> org.apache.axis2.transport:org.apache.axis2.transport.jms.feature:
>>>> ${axis2-transports.wso2.version.1.1.0.wso2v17}
>>>
>>>
>>> and the version `${axis2-transports.wso2.version.1.1.0.wso2v17}` is
>>> replaced with the value of the relevant property we defined in the pom.xml.
>>> Since there are no restrictions like above in defining properties in
>>> pom.xml this works.
>>>
>>> Thanks.
>>>
>>> On Thu, Aug 17, 2017 at 10:39 AM, Niranjan Karunanandham <
>>> niran...@wso2.com> wrote:
>>>
>>>> Hi Kasun,
>>>>
>>>> On Thu, Aug 17, 2017 at 10:04 AM, Kasun Siyambalapitiya <
>>>> kasu...@wso2.com> wrote:
>>>>
>>>>> Hi Niranjan,
>>>>>
>>>>> The build fails before successful generation of the p2-repo by giving
>>>>> the following error
>>>>>
>>>>> [ERROR] Failed to e
Re: [Architecture] C5 Configuration Lookup from Environment Variables
[Adding Chamila] On Mon, Sep 4, 2017 at 2:36 PM, Niranjan Karunanandham <niran...@wso2.com> wrote: > Hi Chamila, > > On Fri, Sep 1, 2017 at 9:57 AM, Chamila De Alwis <chami...@wso2.com> > wrote: > >> Hi, >> >> Please find the meeting notes below. >> >> 1. The existing approach where resorting to the deployment.yaml file to >> figure out lookup hierarchy would be dropped. >> 2. Instead, the lookup hierarchy would be implicit and will be the >> following. >> >> 1. Environment variables >> >> 2. System properties >> >> 3. deployment.yaml file >> >> 4. Default values in the code >> >> 3. Environment variable names will be a standard convention. This would >> conform to existing environment variable naming standards, namely >> having all upper case letters with underscores acting as delimiters. >> 4. System property names will also be a standard convention, where all >> lower case letters would be used with periods being used as delimiters. >> 5. It should be possible to translate map types into environment variable >> names. Array types require more complex conventions that might be >> non-readable. >> 6. Configuration Documentation generation should also include resources >> that specify the list of environment variable names that can be used to set >> the possible values, for the convenience of the users. >> 7. To ease the support process, it should be targetted to create tools >> that collect a given deployments configurations and values. >> 8. Current structure in which Data Sources are defined in the >> Configuration needs to be refined into a Map type for better usability. >> >> Please add any that I might have missed. >> > > In the Carbon 4.4.x, the alias for the secret key was defined in the > component for Secure vault. But there have been instances where the user > wanted to change the secret key, but wasn't able to do so because of it was > defined in the component. Won't there be requests where instead of having a > convention defined by us, the user might want to define his / her own > environment variables for certain properties in the deployment.yaml. > Therefore IMO we need to support environment variable if define in the > deployment.yaml. > > >> >> >> Regards, >> Chamila de Alwis >> Committer and PMC Member - Apache Stratos >> Senior Software Engineer | WSO2 >> Blog: https://medium.com/@chamilad >> >> >> >> On Thu, Aug 31, 2017 at 1:12 PM, Chamila De Alwis <chami...@wso2.com> >> wrote: >> >>> Kind reminder on the meeting at 2.00PM at 7th Floor Banksy room. >>> >>> >>> Regards, >>> Chamila de Alwis >>> Committer and PMC Member - Apache Stratos >>> Senior Software Engineer | WSO2 >>> Blog: https://medium.com/@chamilad >>> >>> >>> >>> On Tue, Aug 29, 2017 at 9:58 AM, Chamila De Alwis <chami...@wso2.com> >>> wrote: >>> >>>> Please note I've pushed the meeting again to Thursday based on >>>> availability. Sorry for the constant notifications. >>>> >>>> >>>> Regards, >>>> Chamila de Alwis >>>> Committer and PMC Member - Apache Stratos >>>> Senior Software Engineer | WSO2 >>>> Blog: https://medium.com/@chamilad >>>> >>>> >>>> >>>> On Mon, Aug 28, 2017 at 10:39 AM, Chamila De Alwis <chami...@wso2.com> >>>> wrote: >>>> >>>>> I've rescheduled the meeting to 30th August (Wednesday) 1pm-2pm, as >>>>> Lakmal is unavailable today. >>>>> >>>>> >>>>> Regards, >>>>> Chamila de Alwis >>>>> Committer and PMC Member - Apache Stratos >>>>> Senior Software Engineer | WSO2 >>>>> Blog: https://medium.com/@chamilad >>>>> >>>>> >>>>> >>>>> On Wed, Aug 23, 2017 at 5:31 PM, Chamila De Alwis <chami...@wso2.com> >>>>> wrote: >>>>> >>>>>> I agree. We could omit Secure Vaulted or possible fields like >>>>>> "password" values from being logged. >>>>>> >>>>>> I've scheduled a meeting on 28th Monday 2.00PM. Let's consolidate >>>>>> these into a plan then. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Chamila de Alwis >>>>>> Committer and PMC Member - Apache St
Re: [Architecture] C5 Configuration Lookup from Environment Variables
;nuw...@wso2.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> @Jayanga, how do you make the server run elegantly on
>>>>>>>>>>>>>> containers without being able to inject properties via env
>>>>>>>>>>>>>> variables?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Aug 23, 2017 at 12:43 PM, Jayanga Dissanayake <
>>>>>>>>>>>>>> jaya...@wso2.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -1, for injecting configs without specifying it in the
>>>>>>>>>>>>>>> deployment.yaml
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Reason: When analyzing most of the issues we request config
>>>>>>>>>>>>>>> files (with C5 deployment.yaml) from the users to identify what
>>>>>>>>>>>>>>> are the
>>>>>>>>>>>>>>> configuration changes. If we have at-least the place holders in
>>>>>>>>>>>>>>> the config
>>>>>>>>>>>>>>> files, there is a guarantee that we know what are the injected
>>>>>>>>>>>>>>> configuration and we could request the actual values of the
>>>>>>>>>>>>>>> configs we need.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But with the suggested approach, we have to request the
>>>>>>>>>>>>>>> 1)config files, 2)all the environment variables and get the
>>>>>>>>>>>>>>> union to
>>>>>>>>>>>>>>> identify the changed configurations. IMO an additional effort.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hence considering the overhead on the support front I am -1
>>>>>>>>>>>>>>> for the suggested approach.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Jayanga.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *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>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Aug 23, 2017 at 9:16 AM, Danesh Kuruppu <
>>>>>>>>>>>>>>> dan...@wso2.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Created git issue[1] to track this improvement.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. https://github.com/wso2/carbon-config/issues/48
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Aug 22, 2017 at 9:50 AM, Danesh Kuruppu <
>>>>>>>>>>>>>>>> dan...@wso2.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Chamila,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> +1 for the suggested approach. So we can have both ways to
>>>>>>>>>>>>>>>>> set environment variables either from placeholder
>>>>>>>>>>>>>>>>> ${env:} where we can
>>>>>>>>>>>>>>>>> specify any key for the variable or from the new approach.
>>>>>>>>>>>>>>>>> For the new
>>>>>>>>>>>>>>>>> approach, we need adhere to a certain format as suggested.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Danesh
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Aug 21, 2017 at 5:59 PM, Chamila De Alwis <
>>>>>>>>>>>>>>>>> chami...@wso2.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In C5, the configuration lookup is done in the
>>>>>>>>>>>>>>>>>> environment variables, system properties, deployment.yaml
>>>>>>>>>>>>>>>>>> file, and the
>>>>>>>>>>>>>>>>>> value provided in the configuration bean class, in that
>>>>>>>>>>>>>>>>>> order. However, it
>>>>>>>>>>>>>>>>>> looks like environment variable lookup happens only if the
>>>>>>>>>>>>>>>>>> particular
>>>>>>>>>>>>>>>>>> configuration is noted to do so in the deployment.yaml,
>>>>>>>>>>>>>>>>>> specifically if the
>>>>>>>>>>>>>>>>>> value of the config is prefixed by a placeholder env:.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> gateWayEndpoint: ${env:gateWayEndpoint}
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> While this pattern may be easy to implement, it is
>>>>>>>>>>>>>>>>>> cumbersome to be followed in a Containerization approach and
>>>>>>>>>>>>>>>>>> IMO breaks the
>>>>>>>>>>>>>>>>>> 12Factor approach to configuration. This is because of the
>>>>>>>>>>>>>>>>>> need to edit a
>>>>>>>>>>>>>>>>>> physical file in order for the environment variables to be
>>>>>>>>>>>>>>>>>> queried. This
>>>>>>>>>>>>>>>>>> makes it harder to maintain a single Container Image for
>>>>>>>>>>>>>>>>>> different
>>>>>>>>>>>>>>>>>> deployments, and manipulate the Container runtimes via
>>>>>>>>>>>>>>>>>> environment
>>>>>>>>>>>>>>>>>> variables.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> AFAIU, this pattern emerges from the requirements in
>>>>>>>>>>>>>>>>>> SecureVault; having a ${sec:} prefix can mark the
>>>>>>>>>>>>>>>>>> configuration value to be
>>>>>>>>>>>>>>>>>> resolved through Secure Vault resolver. However IMO this,
>>>>>>>>>>>>>>>>>> value resolution,
>>>>>>>>>>>>>>>>>> is not the same as value lookup.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> IMO, the following should be the lookup order, without
>>>>>>>>>>>>>>>>>> having to mark a particular config in the deployment.yaml
>>>>>>>>>>>>>>>>>> file.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. Environment variables:
>>>>>>>>>>>>>>>>>> PREFIX_wso2.NAMESPACE_CONFIGKEY="value",
>>>>>>>>>>>>>>>>>> PREFIX_wso2.NAMESPACE_CONFIGPARENT_CONFIG2="value2"
>>>>>>>>>>>>>>>>>> 2. deployment.yaml:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> wso2.NAMESPACE:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> CONFIG_KEY: value
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> CONFIG_PARENT:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> CONFIG2: valu2
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 3. Default value in the code
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This approach would be most Container friendly one as
>>>>>>>>>>>>>>>>>> there is no need to change files depending on deployment
>>>>>>>>>>>>>>>>>> patterns,
>>>>>>>>>>>>>>>>>> environments, etc.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>> Chamila de Alwis
>>>>>>>>>>>>>>>>>> Committer and PMC Member - Apache Stratos
>>>>>>>>>>>>>>>>>> Senior Software Engineer | WSO2
>>>>>>>>>>>>>>>>>> Blog: https://medium.com/@chamilad
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Danesh Kuruppu*
>>>>>>>>>>>>>>>>> Senior Software Engineer | WSO2
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Email: dan...@wso2.com
>>>>>>>>>>>>>>>>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
>>>>>>>>>>>>>>>>> Web: WSO2 Inc <https://wso2.com/signature>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Danesh Kuruppu*
>>>>>>>>>>>>>>>> Senior Software Engineer | WSO2
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Email: dan...@wso2.com
>>>>>>>>>>>>>>>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
>>>>>>>>>>>>>>>> Web: WSO2 Inc <https://wso2.com/signature>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ___
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Nuwan Dias
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>>>>>>>>>>>> email : nuw...@wso2.com
>>>>>>>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ___
>>>>>>>>>>>>>> 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 and Regards,
>>>>>>>>>>>
>>>>>>>>>>> Isuru H.
>>>>>>>>>>> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>*
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Lakmal Warusawithana
>>>>>>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>>>>>>> Mobile : +94714289692 <071%20428%209692>
>>>>>>>>>> Blogs : https://medium.com/@lakwarus/
>>>>>>>>>> http://lakmalsview.blogspot.com/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Thanks and Regards,
>>>>>>>>>
>>>>>>>>> Isuru H.
>>>>>>>>> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nuwan Dias
>>>>>>
>>>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>>>> email : nuw...@wso2.com
>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
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
Re: [Architecture] Same feature with different versions in different runtimes
Hi Kasun, On Thu, Aug 17, 2017 at 10:04 AM, Kasun Siyambalapitiya <kasu...@wso2.com> wrote: > Hi Niranjan, > > The build fails before successful generation of the p2-repo by giving the > following error > > [ERROR] Failed to execute goal org.wso2.carbon.maven:carbon-f >> eature-plugin:3.1.1:generate-repo (p2-repo-generation) on project >> wso2carbon-kernel: Feature org.wso2.carbon.pax.exam.feature_5.2.0.1 not >> found -> [Help 1] > > > > Since in the new C5 model the p2-repo containing all the features required > for all the runtimes of the product, is generated at a single specified > directory(by default the target directory) multiple version of the same > feature cannot be generated as maven build will pick only one version of > the dependency due to the use of "nearest in the dependency tree" strategy > as shown in above mail. As a result although we can have multiple versions > at the p2-repo per feature due to the above nature of maven, runtimes with > different feature versions cannot be created in C5. This problem was not > there in the previous C4 model as the profiles(runtime in C5 wording) were > generated at separate locations and their respective p2-repos were created > at their own locations(where the profile is created) [1] > > IMO this issue can be avoided by always using the newest feature version > available when creating runtimes in C5 products. WDYT? > The profiles that were used in C4 were used to install features, but only one p2-repo is created. In the case of EI, they have created separate modules (folders for each profile) and then they are handling it. In the case of AS 5.3.0, we had a single pom to create a distribution with multiple profiles. Wilkes p2-repo is generated using the carbon-feature-repository [1], here in the pom, the p2-repo is generated with different versions of the same feature. Similarly for C5, it should follow the same. We need to look into the carbon-maven-plugins version 1.5.x [2] and 3.x [3]. > > [1] https://github.com/wso2/product-ei/tree/v6.2.0-m2/p2-profile > > On Wed, Aug 16, 2017 at 3:51 PM, Niranjan Karunanandham <niran...@wso2.com > > wrote: > >> Hi Kasun, >> >> On Wed, Aug 16, 2017 at 3:30 PM, Kasun Siyambalapitiya <kasu...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> When I was creating a custom product using carbon-kernel version >>> 5.2.0-alpha[1] the following issue aroused. >>> In a scenario where a product is build with 2 runtimes called runtimeA >>> and runtimeB. >>> >>> runtimeA contains the below feature among it's other features >>> >>> pax.exam.feature v5.2.0.0 >>> sample-bundle2 v5.2.0.0 >>> log-bundle v1.5.0 >>> >>> >>> while runtmeB contains the below feature among it's other features >>> >>> sample.feature v5.2.0.1 >>> sample-bundle1 v5.2.0.0 >>> monitor-bundle v1.5.0 >>> pax.exam.feature v5.2.0.1 >>> >>> >>> >>> As shown above since there is a dependency to the >>> `pax.exam.feature,v5.2.0.1` from the `sample.feature,v5.2.0.1`, to have >>> both versions of `pax.exam.feature` to be installed into the separate >>> runtimes of the product, it is required to define dependency information of >>> each `pax.exam.feature` versions (v5.2.0.0 and v5.2.0.1) under the >>> tag in the pom.xml file. >>> >>> But during the build process, maven will only pick one version of that >>> dependency and omit the other versions to avoid any conflicts using the >>> *"nearest >>> in the dependency tree"* strategy (already asked in stackoverflow [1]). >>> This will results in a build failure as if the build process resolves >>> dependency of `pax.exam.feature` v5.2.0.0`, the version v5.2.0.1 will not >>> be available during build and vice versa. >>> >>> Is this a legitimate case that we should address? >>> IMO it will be a best practise to use the newest versions of the >>> features available when creating runtimes than using the older versions >>> which in turn will resolve this issue. >>> >>> Your comments are highly appreciated. >>> >> >> As per the offline discussion, this issue is for generating the p2-repo. >> You will need to check whether both versions of the feature are there in >> the p2-repo that is being generated. If it does not exist then we would >> need to fix it there. >> >> >>> >>> [1] https://github.com/wso2/carbon-kernel/tree/v5.2.0-alpha >>> [2] https://stackoverflow.com/questions/24
Re: [Architecture] Same feature with different versions in different runtimes
Hi Kasun, On Wed, Aug 16, 2017 at 3:30 PM, Kasun Siyambalapitiya <kasu...@wso2.com> wrote: > Hi all, > > When I was creating a custom product using carbon-kernel version > 5.2.0-alpha[1] the following issue aroused. > In a scenario where a product is build with 2 runtimes called runtimeA and > runtimeB. > > runtimeA contains the below feature among it's other features > > pax.exam.feature v5.2.0.0 > sample-bundle2 v5.2.0.0 > log-bundle v1.5.0 > > > while runtmeB contains the below feature among it's other features > > sample.feature v5.2.0.1 > sample-bundle1 v5.2.0.0 > monitor-bundle v1.5.0 > pax.exam.feature v5.2.0.1 > > > > As shown above since there is a dependency to the > `pax.exam.feature,v5.2.0.1` from the `sample.feature,v5.2.0.1`, to have > both versions of `pax.exam.feature` to be installed into the separate > runtimes of the product, it is required to define dependency information of > each `pax.exam.feature` versions (v5.2.0.0 and v5.2.0.1) under the > tag in the pom.xml file. > > But during the build process, maven will only pick one version of that > dependency and omit the other versions to avoid any conflicts using the > *"nearest > in the dependency tree"* strategy (already asked in stackoverflow [1]). > This will results in a build failure as if the build process resolves > dependency of `pax.exam.feature` v5.2.0.0`, the version v5.2.0.1 will not > be available during build and vice versa. > > Is this a legitimate case that we should address? > IMO it will be a best practise to use the newest versions of the features > available when creating runtimes than using the older versions which in > turn will resolve this issue. > > Your comments are highly appreciated. > As per the offline discussion, this issue is for generating the p2-repo. You will need to check whether both versions of the feature are there in the p2-repo that is being generated. If it does not exist then we would need to fix it there. > > [1] https://github.com/wso2/carbon-kernel/tree/v5.2.0-alpha > [2] https://stackoverflow.com/questions/24962607/multiple- > versions-of-the-same-dependency-in-maven > > Thanks > > -- > *Regards,* > > *Kasun Siyambalapitiya* > *Software Engineer* > WSO2 Inc. - http://wso2.com/ > lean . enterprise . middleware > Tel : 0715523466 > E mail : kasu...@wso2.com > Blog: https://medium.com/@kasunsiyambalapitiya > <https://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
Re: [Architecture] Multiple runtime support for C5 based products
Hi Thusitha, On Mon, Aug 14, 2017 at 12:08 PM, Thusitha Thilina Dayaratne < thusit...@wso2.com> wrote: > Hi Jayanga, > > From the beginning of C5, we tried to achieve a clear separation between, >> User(Custom) space and Server space. >> IMO, having just a single deployment directory (for both custom and >> server artifacts) won't help to maintain that separation. > > We are having 2 deployment directories. > >1. //deployment >2. /deployment > > The issue is in existing API we have a method to deploy/upload the given > artifact to the deployment directory. This was not an issue previously coz > we had only single deployment dir. But since now we have multiple > deployment dirs, where should we deploy the artifact? > When are we using this method, i.e., the use-case? If the artifact is within the either the runtime deployment or serverhome deployment directory, then based on that the artifact can be deployed in the corresponding directory. > > Thanks > Thusitha > > On Mon, Aug 14, 2017 at 11:15 AM, Jayanga Dissanayake <jaya...@wso2.com> > wrote: > >> Hi Thusitha/Nira, >> >> From the beginning of C5, we tried to achieve a clear separation between, >> User(Custom) space and Server space. >> IMO, having just a single deployment directory (for both custom and >> server artifacts) won't help to maintain that separation. >> >> WDYT? >> >> Thanks, >> Jayanga. >> >> *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> >> >> On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham < >> niran...@wso2.com> wrote: >> >>> Hi, >>> >>> On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne < >>> thusit...@wso2.com> wrote: >>> >>>> Hi All, >>>> >>>> In c5 carbon-deployment we have a method to manually deploy artifacts >>>> where we only provide artifact's path and artifact type. This was no issue >>>> until 5.2.0-m3 since we only had a single deployment directory. >>>> public void deploy(String artifactPath, ArtifactType artifactType)[1] >>>> >>>> But since we have 2 deployment directories with the new >>>> runtime architecture. So how should we handle this deployment? >>>> AFAIU options would be as follows >>>> >>>>1. Add a new API(method) to get the relevant deployment dir and >>>>deploy to that >>>>2. We have to prioritize a deployment directory (Server or runtime) >>>>and deploy only to the prioritized one >>>>3. Deploy to both deployment dirs >>>> >>>> >>>> >>> In the new deployment directory, each runtime will have a deployment >>> directory and there will be on outside. The runtime deployment will be for >>> wso2 artifacts. AFAIU with previous model (C4), the above method is used by >>> when a user uploads the artifact from a UI. Therefore IMO the default >>> method should deploy the artifact to the deployment directory outside the >>> runtime, i.e., /deployment. >>> >>> >>>> [1] - https://github.com/wso2/carbon-deployment/blob/master/comp >>>> onents/org.wso2.carbon.deployment.engine/src/main/java/org/w >>>> so2/carbon/deployment/engine/DeploymentService.java#L43 >>>> >>>> Thanks >>>> Thusitha >>>> >>>> >>>> On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu <dan...@wso2.com> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Correction: Proposed directory structure needed to be change as below. >>>>> instead of having deployment directory per runtime, we will have only >>>>> deployment directory per server distribution. This deployment directory >>>>> contains custom deployable artifacts. So ideally there won't be any >>>>> artifact in default distribution. >>>>> >>>>> Though we have packaging all runtimes in one distribution. we are not >>>>> encouraging to run all runtime from the single pack. So we are going to >>>>> provide a script to exact runtime from the distribution pack. >>>>> >>>>> ServerHome >>>>>>|_ bin >>>>>>
Re: [Architecture] Multiple runtime support for C5 based products
t;> | |___ deployment >>> | >>> |___ Runtime1 >>> | |___ bin >>> | | |__ carbon.sh >>> | |___ deployment >>> | >>> |___ Runtime2 >>> | |___ bin >>> | | |_ carbon.sh >>> | |___ deployment >>> | >>> |___ lib (this will contains common jars) >>> >>> >> Thanks >> -- >> >> *Danesh Kuruppu* >> Senior Software Engineer | WSO2 >> >> Email: dan...@wso2.com >> Mobile: +94 (77) 1690552 <+94%2077%20169%200552> >> Web: WSO2 Inc <https://wso2.com/signature> >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thusitha Dayaratne > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > Mobile +94712756809 <+94%2071%20275%206809> > Blog alokayasoya.blogspot.com > Abouthttp://about.me/thusithathilina > <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
Re: [Architecture] C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)
Hi all, On Mon, May 22, 2017 at 10:47 PM, Nisala Nanayakkara <nis...@wso2.com> wrote: > Hi Jayanga, > > +1 for maintaining separate directory for log, pre-QA patches/updates with > a proper name. I assume that the pre-QA patches/updates are still valid in > C5. So names such as "information-collector" or "log-collector" will not be > an option. Because this directory will not only contains log > patches/updates. Moreover maintaining separate directory will provide us > more convenient way to filter the changes into wso2 packed jars and > generate a log file with this changes. Since applying log, pre-QA > patch/update is only one time task, We can provide command-line option to > get updates/patches from this separate directory as Ruwan mentioned. So it > will not affect use-cases such as adding DB drivers, configuring > additional transports (e.g: JMS) and etc. > IMO we do not need to have a command line option for this. Currently for C5, we have a listener for the lib folder and apply it to the current runtime's bundle.info. In production, the recommendation is to comment this listener and to apply the jars in lib to the runtime's bundles.info using osgi-lib.sh [1]. Similarly for the temp fix / log patch, IMO we can have a separate folder with a listener which by default is commented off so that it does not scan the folder during server startup. Since this is a testing purpose, we do not need a separate command line tool. Only when required for testing purpose, we can enable the listener. It would be better so that we have a proper precedence as below: *"new folder" > plugins > lib* where ">" means higher precedence > > Thanks, > Nisala > > On Mon, May 22, 2017 at 5:20 PM, Jayanga Dissanayake <jaya...@wso2.com> > wrote: > >> Hi Ramith/Nira >> >> On Mon, May 22, 2017 at 2:56 PM, Niranjan Karunanandham < >> niran...@wso2.com> wrote: >> >>> >>> On Mon, May 22, 2017 at 12:34 PM, Ramith Jayasinghe <ram...@wso2.com> >>> wrote: >>> >>>> what I was thinking is if there is a anyway we can record the fact that >>>> this patch is a log/preqa may be by adding (custom?) meta data. >>>> then at least a warning saying 'there is a pre-qa/log patch available >>>> during the server start up. >>>> >>> I agree with Ramith. In 4.4.x, we mention when patches are applied in >>> the patch.log. IMO it would be better if we can record something similar to >>> this when temp updates are applied to the system. This will help us in the >>> support front by checking the logs if there are any temp jars applied. >>> >>> Thanks for the suggestion. Currently, we log a sample message like >>> below when we are updateing the bundles.info file. >>> "Successfully updated the OSGi bundle information of Carbon Runtime: >>> default" >>> >>> But this happens only once, at the very first time you are starting with >>> the new jar. Consequent restarts would not log the given message as there >>> is no update. In C4 we had patch log, in the C5 we havent thought of such >>> file yet. I would be better to have the custom user bundles and log/pre-qa >>> bundle information in the logs. We will check the possibility of adding >>> this to the logs with minimal effect to the server startup time. >>> >> >>> >>>> >>>> >>>> On Mon, May 22, 2017 at 12:17 PM, Jayanga Dissanayake <jaya...@wso2.com >>>> > wrote: >>>> >>>>> Hi Ramith, >>>>> >>>>> Inside the server, there is no way to distinguish whether it is a >>>>> log/pre-qa, it will just be a bundle with same symbolic name and the >>>>> version >>>>> We might specify log/pre-qa in the zip file we provide to the client. >>>>> >>>>> Can you please explain more on the validations that you would expect, >>>>> so that I could look more into the possibilities whether those are >>>>> feasible with the currently proposed methodology. >>>>> >>>>> Thanks, >>>>> Jayanga. >>>>> >>>>> >>>>> *Jayanga Dissanayake* >>>>> Associate Technical Lead >>>>> WSO2 Inc. - http://wso2.com/ >>>>> lean . enterprise . middleware >>>>> email: jaya...@wso2.com >>>>> mobile: +94772207259 <077%20220%207259> >>>>> <http://wso2.com/signature> >>>>> >>>>> On Mon, Ma
Re: [Architecture] C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)
In-addition, in C5 by default, it scans the lib folder and updates the corresponding runtime's bundles.info. But in a production environment, our suggestion is to switch this off so that we can reduce the server startup time. In C5, there is a configuration to switch this off, and there is a separate script file to write selective components in the lib folder to each runtime's bundle.info separately before starting up the server. Regards, Nira On Mon, May 22, 2017 at 2:54 PM, Niranjan Karunanandham <niran...@wso2.com> wrote: > Hi Jayanga, > > > On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <jaya...@wso2.com> > wrote: > >> Hi Niranjan, >> >> Having another directory for patches would add an empty directory to the >> current pack structure. And having the name "patch" is not >> correct according to the C5 way, as we are proving fixes as updates. >> > > Well we do not have to call it "patch", it can be called "update" or some > other name :) > > >> >> Another point is, having many places to put bundles will complicate our >> story, Hence, I would prefer to have one place where users put bundles >> into. If that bundle is having a symbolic name and version equivalent to a >> one in the plugins directory, it will act as a "patch" or else it will be >> treated as a separate bundle. >> > > Yes, I agree that this will be an empty folder. The reason for my > suggestion is that unlike the other components in the lib folder, this temp > jar will be of the same version as that in the plugins (since this is a > temp jar, IMO we do not need to change the version). Also allowing the jars > in the lib folder to overwrite the plugins folder IMO is wrong because lib > is the place for the customer to add his components and it should not > overwrite the server components, i.e., in the plugins. IMO having this in a > separate location would be clean, since then we give that particular > directory higher precedence than the plugins folder and this folder should > be used for temp purpose only. > > >> >> Thanks, >> Jayanga. >> >> *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> >> >> On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham < >> niran...@wso2.com> wrote: >> >>> Hi Jayanga, >>> >>> IMO we should also take into consideration of apply fixes other than >>> just log patches. In C5 onwards, the current approach is to use WUM to >>> deliver all updates. But there can be scenarios where we would need to >>> provide an immediate solution or say a Pre-QA fix. IMO we would need to >>> address this here. >>> >>> IMO applying the temp fix in lib folder is not correct. IMO the Lib >>> folder is used for addition components that are required by the server, >>> i.e., components which are not provided by wso2. IMO it would be better to >>> have a separate folder for this. In carbon 4.4.X, we had a separate folder >>> called patches. >>> >>> Regards, >>> Nira >>> >>> On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <jaya...@wso2.com> >>> wrote: >>> >>>> Hi Vidura, >>>> >>>> Adding a separate command line would easily lead to more human errors. >>>> With C5, we are trying to minimize the configurations, command >>>> line parameters, etc. to make the users' life easier and to reduce the >>>> human errors much as possible. Log patch is just a one case I highlighted. >>>> There are other use cases like; >>>> >>>>- Adding DB drivers >>>>- Configuring additional transports e.g: JMS >>>>- Putting custom mediators (in C4), etc. >>>> >>>> Above requirements are based on the C4 experience and there will >>>> definitely be some similar set of requirements in the C5 as well. Hence, if >>>> we introduce a separate command line, the user will have to start the >>>> server with that parameter each time they modify the lib directory, even >>>> they do a version upgrade of a given library. >>>> Hence I would prefer to make the library update >>>> decision programmatically rather a user input. >>>> >>>> @Lackman: >>>> With C5, we will abandon the word "patch". Everything including >
Re: [Architecture] C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)
On Mon, May 22, 2017 at 12:34 PM, Ramith Jayasinghe <ram...@wso2.com> wrote: > what I was thinking is if there is a anyway we can record the fact that > this patch is a log/preqa may be by adding (custom?) meta data. > then at least a warning saying 'there is a pre-qa/log patch available > during the server start up. > I agree with Ramith. In 4.4.x, we mention when patches are applied in the patch.log. IMO it would be better if we can record something similar to this when temp updates are applied to the system. This will help us in the support front by checking the logs if there are any temp jars applied. > > > On Mon, May 22, 2017 at 12:17 PM, Jayanga Dissanayake <jaya...@wso2.com> > wrote: > >> Hi Ramith, >> >> Inside the server, there is no way to distinguish whether it is a >> log/pre-qa, it will just be a bundle with same symbolic name and the version >> We might specify log/pre-qa in the zip file we provide to the client. >> >> Can you please explain more on the validations that you would expect, so >> that I could look more into the possibilities whether those are >> feasible with the currently proposed methodology. >> >> Thanks, >> Jayanga. >> >> >> *Jayanga Dissanayake* >> Associate Technical Lead >> WSO2 Inc. - http://wso2.com/ >> lean . enterprise . middleware >> email: jaya...@wso2.com >> mobile: +94772207259 <077%20220%207259> >> <http://wso2.com/signature> >> >> On Mon, May 22, 2017 at 12:01 PM, Ramith Jayasinghe <ram...@wso2.com> >> wrote: >> >>> is there a way we can flag a patch to be something 'temporary' (such as >>> a log/pre-qa)? if so may be we can do some validation surrounding that? >>> >>> On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <jaya...@wso2.com> >>> wrote: >>> >>>> Hi Niranjan, >>>> >>>> Having another directory for patches would add an empty directory to >>>> the current pack structure. And having the name "patch" is not >>>> correct according to the C5 way, as we are proving fixes as updates. >>>> >>>> Another point is, having many places to put bundles will complicate our >>>> story, Hence, I would prefer to have one place where users put bundles >>>> into. If that bundle is having a symbolic name and version equivalent to a >>>> one in the plugins directory, it will act as a "patch" or else it will be >>>> treated as a separate bundle. >>>> >>>> Thanks, >>>> Jayanga. >>>> >>>> *Jayanga Dissanayake* >>>> Associate Technical Lead >>>> WSO2 Inc. - http://wso2.com/ >>>> lean . enterprise . middleware >>>> email: jaya...@wso2.com >>>> mobile: +94772207259 <077%20220%207259> >>>> <http://wso2.com/signature> >>>> >>>> On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham < >>>> niran...@wso2.com> wrote: >>>> >>>>> Hi Jayanga, >>>>> >>>>> IMO we should also take into consideration of apply fixes other than >>>>> just log patches. In C5 onwards, the current approach is to use WUM to >>>>> deliver all updates. But there can be scenarios where we would need to >>>>> provide an immediate solution or say a Pre-QA fix. IMO we would need to >>>>> address this here. >>>>> >>>>> IMO applying the temp fix in lib folder is not correct. IMO the Lib >>>>> folder is used for addition components that are required by the server, >>>>> i.e., components which are not provided by wso2. IMO it would be better to >>>>> have a separate folder for this. In carbon 4.4.X, we had a separate folder >>>>> called patches. >>>>> >>>>> Regards, >>>>> Nira >>>>> >>>>> On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake < >>>>> jaya...@wso2.com> wrote: >>>>> >>>>>> Hi Vidura, >>>>>> >>>>>> Adding a separate command line would easily lead to more human >>>>>> errors. With C5, we are trying to minimize the configurations, command >>>>>> line parameters, etc. to make the users' life easier and to reduce the >>>>>> human errors much as possible. Log patch is just a one case I >>>>>> highlighted. >>>>>> There are other use cases like;
Re: [Architecture] C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)
Hi Jayanga, On Mon, May 22, 2017 at 11:52 AM, Jayanga Dissanayake <jaya...@wso2.com> wrote: > Hi Niranjan, > > Having another directory for patches would add an empty directory to the > current pack structure. And having the name "patch" is not > correct according to the C5 way, as we are proving fixes as updates. > Well we do not have to call it "patch", it can be called "update" or some other name :) > > Another point is, having many places to put bundles will complicate our > story, Hence, I would prefer to have one place where users put bundles > into. If that bundle is having a symbolic name and version equivalent to a > one in the plugins directory, it will act as a "patch" or else it will be > treated as a separate bundle. > Yes, I agree that this will be an empty folder. The reason for my suggestion is that unlike the other components in the lib folder, this temp jar will be of the same version as that in the plugins (since this is a temp jar, IMO we do not need to change the version). Also allowing the jars in the lib folder to overwrite the plugins folder IMO is wrong because lib is the place for the customer to add his components and it should not overwrite the server components, i.e., in the plugins. IMO having this in a separate location would be clean, since then we give that particular directory higher precedence than the plugins folder and this folder should be used for temp purpose only. > > Thanks, > Jayanga. > > *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> > > On Mon, May 22, 2017 at 10:52 AM, Niranjan Karunanandham < > niran...@wso2.com> wrote: > >> Hi Jayanga, >> >> IMO we should also take into consideration of apply fixes other than just >> log patches. In C5 onwards, the current approach is to use WUM to deliver >> all updates. But there can be scenarios where we would need to provide an >> immediate solution or say a Pre-QA fix. IMO we would need to address this >> here. >> >> IMO applying the temp fix in lib folder is not correct. IMO the Lib >> folder is used for addition components that are required by the server, >> i.e., components which are not provided by wso2. IMO it would be better to >> have a separate folder for this. In carbon 4.4.X, we had a separate folder >> called patches. >> >> Regards, >> Nira >> >> On Fri, May 19, 2017 at 10:46 AM, Jayanga Dissanayake <jaya...@wso2.com> >> wrote: >> >>> Hi Vidura, >>> >>> Adding a separate command line would easily lead to more human errors. >>> With C5, we are trying to minimize the configurations, command >>> line parameters, etc. to make the users' life easier and to reduce the >>> human errors much as possible. Log patch is just a one case I highlighted. >>> There are other use cases like; >>> >>>- Adding DB drivers >>>- Configuring additional transports e.g: JMS >>>- Putting custom mediators (in C4), etc. >>> >>> Above requirements are based on the C4 experience and there will >>> definitely be some similar set of requirements in the C5 as well. Hence, if >>> we introduce a separate command line, the user will have to start the >>> server with that parameter each time they modify the lib directory, even >>> they do a version upgrade of a given library. >>> Hence I would prefer to make the library update >>> decision programmatically rather a user input. >>> >>> @Lackman: >>> With C5, we will abandon the word "patch". Everything including >>> features, fixes, etc. will be provided via updates. Hence there is no point >>> having a separate directory call "patches". A "log patch" is just another >>> jar file having the same bundle symbolic name and version as its original >>> bundle in the plugins directory. Once it is removed from the lib directory, >>> the server will use the original bundle in the plugins directory. >>> >>> Thanks, >>> Jayanga. >>> >>> >>> >>> *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> >>> >>> On Thu, May 18, 2017 at 12:06 PM, Lakshman Udayakantha < &g
Re: [Architecture] C5 Modifying OSGi bundle deployment logic to support temporary patches (log patches, etc)
with >>>>>> the same bundle-symbolic-name and version into the plugins directory it >>>>>> will be ignored. >>>>>> >>>>>> To achieve this behavior we have to modify the existing OSGi bundle >>>>>> deployment logic as follows. >>>>>> >>>>>> 1. In the first run make a backup of the original bundles.info file >>>>>> (bundles.info.original this will be used as the baseline for each time it >>>>>> updated the bundles.info file) >>>>>> 2. Read the bundles.info.original file >>>>>> 3. Add the bundles in the [product_home]/lib directory >>>>>> 4. Update the bundles.info file >>>>>> And >>>>>> The logic in selecting effective bundles list should be changed to >>>>>> not to give priority to bundles in the plugins directory. Instead modify >>>>>> the entries, if a similar bundle (symbolic name and version) is found in >>>>>> the [product_home]/lib >>>>>> >>>>>> Above suggested approach allows easily add the patched jars into the >>>>>> [product_home]/lib directory for temporary purposes. And reverting the >>>>>> patch is also possible as we have a backup of the original >>>>>> bundles.info file >>>>>> >>>>>> WDYT? >>>>>> >>>>>> [1] https://github.com/wso2/carbon-kernel/blob/v5.2.0-m3/lau >>>>>> ncher/src/main/java/org/wso2/carbon/launcher/extensions/OSGi >>>>>> LibBundleDeployerUtils.java >>>>>> >>>>>> 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> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Ruwan Abeykoon* >>>>> *Associate Director/Architect**,* >>>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >>>>> *lean.enterprise.middleware.* >>>>> >>>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> 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 >>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Lakshman Udayakantha >> WSO2 Inc. www.wso2.com >> lean.enterprise.middleware >> Mobile: *0717429601* >> >> >> ___ >> 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 > > -- *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
Re: [Architecture] Multiple runtime support for C5 based products
Hi, On Tue, Apr 18, 2017 at 11:35 AM, Jayanga Dissanayake <jaya...@wso2.com> wrote: > Hi Danesh, > > +1 for the suggested approach. > It will allow keeping the /wso2 directory untouched by the users. > > And having different key stores for different runtimes is a valid > use-case. Hence +1 for having secvault and transport keys stores with > different names for each runtime in the /resources/security directory. > IMO we need not have separate jks for each runtime because in a default pack this will be the same for all the runtime and we will be only duplicating it. If the customer wants to have a separate one then they can configure it in the deployment.yaml per runtime and point to a separate jks (for securce vault and SSL, if required) for each runtime. > > Thanks, > Jayanga. > > *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> > > On Tue, Apr 18, 2017 at 9:42 AM, Danesh Kuruppu <dan...@wso2.com> wrote: > >> Hi Thusitha, >> >> >>> Shouldn't we move resource dir to as well? AFAIU each >>> runtime can have their own JKS. WDYT? >>> >> >> Current idea is to have common jks files(one jks for securevault and one >> for the transport) for all runtime in the distribution. Since this also can >> change by the end user, we need to move out from the wso2 directory. If we >> need to keep them per runtime, we can keep them in the same location with >> different name and refer it from the runtime configuration file. >> >> WDYT? >> >> Thanks >> -- >> >> *Danesh Kuruppu* >> Senior Software Engineer | WSO2 >> >> Email: dan...@wso2.com >> Web: WSO2 Inc <https://wso2.com/signature> >> >> >> ___ >> 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 > > 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
Re: [Architecture] Multiple runtime support for C5 based products
Hi Thusitha,
On Thu, Mar 30, 2017 at 2:10 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:
> Since there will be multiple runtimes in a single product we need to get
> the information such as current runtime name/path etc..
>
> According to the EI structure, the startup script for each runtime resides
> in the <*ServerHome>/wso2/{runtime}/bin *directory. And there is a
> corresponding script at <*ServerHome>/bin* which will call the particular
> runtime's startup script. Do we follow the same structure or we put all
> the startup scripts in the <*ServerHome>/bin* directory?
>
> IMHO We have following options
>
> *Option 1* - All startup scripts are in <*ServerHome>/wso2/{runtime}/bin *and
> linker script in <*ServerHome>/bin *(Similar to EI structure)
>
>- Kernel feature can set the runtime.home based om the script location
>(which will be required for config resolver and etc..) from the carbon.sh
>so product teams don't have to change the default carbon.sh
>
> +1 for this option. In this way other products need not maintain runtime
specific carbon.sh file. This should come along with the Kernel runtime
specific feature. In-addition to this, it would be nice if the startall
script in the /bin finds the runtimes dynamically without
having specify it in the script. IMO we can get all the runtime which has a
carbon.sh file inside its bin directory or getting all the folder names in
/wso2 excluding lib folder.
>
>-
>
> *Option 2* - All startup scripts are in <*ServerHome>/bin*
>
>- We can assume the startup script name is equivalent to runtime name.
>apim.sh and set that as runtime.home.
>- Product teams have to rename the default carbon.sh file to
>relevant runtime name
>
> *Option 3 *- Can be any of above 2 options
>
>- Default carbon.sh will set the runtime.home to "default" and product
>team have to edit default script and change the runtime.home value in
>product level.
>
> WDYT?
>
> Thanks
> Thusitha
>
>
>
> On Wed, Mar 8, 2017 at 8:33 PM, KasunG Gajasinghe <kas...@wso2.com> wrote:
>
>> Hi Danesh,
>>
>> Please find some comments in-line.
>>
>> On Wed, Mar 8, 2017 at 8:16 PM, Danesh Kuruppu <dan...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> In C5 based products, we can have multiple runtimes in the product
>>> package. For each runtime, there will be configuration(deployment.yaml),
>>> securevault, execution scripts(carbon.sh etc), logs, deployment specific
>>> only for that runtime. resources(wso2carbon.jks) and lib directory will be
>>> common to every runtime and those are placed at top level.
>>> So the directory structure of the basic distribution will be something
>>> like,
>>>
>>>
>>
>> What's the difference between top-level conf/ folder and the conf/
>> folders under runtimes?
>>
>> And, how will this new directory structure affect the p2.inf
>> instructions? In the p2.inf, we define from/where to the config files.
>>
>>
>>
>>> wso2-carbon
>>>> |-- bin
>>>> |-- resources
>>>> |-- lib
>>>> |-- conf
>>>> |-- wso2
>>>> |--
>>>> |-- bin
>>>> |-- logs
>>>> |-- conf
>>>> |-- deployment.yaml
>>>> |-- log4j2.xml
>>>> |-- security
>>>> |-- secure-vault.yaml
>>>> |-- secrets.properties
>>>> |-- deployment
>>>> |--
>>>>
>>>> |--
>>>> |-- lib
>>>> |-- features
>>>> |-- p2
>>>> |-- plugins
>>>>
>>>
>>>
>>>
>>> Each runtime will be started as different processes/JVM and for the
>>> distributed setup, we are going to provide a tool to run each runtime in
>>> different nodes/containers.
>>>
>>
>> Does this mean we can run multiple runtimes at the same time from a given
>> product instance?
>>
>> Thanks,
>> KasunG
>>
>>
>>> We are currently working on this. Please share your thoughts /
>>> suggestions.
>>>
>>> Thanks
>>> --
>>>
>>> *Danesh Kuruppu*
>>> Senior Software Engineer | WSO2
>>>
>>> Email: dan...@wso2.com
>>> Mobile: +94 (77) 1690552 <077%20169%200552>
>>> Web: WSO2 Inc <https://wso2.com/signature>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture
Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration
Hi Jayanga, On Fri, Mar 17, 2017 at 10:09 AM, Jayanga Dissanayake <jaya...@wso2.com> wrote: > Hi Niranjan, > > You are correct we should follow the same way as msf4j to detect whether > it is OSGi mode or not. > The properties suggested are to avoid the OSGi mode check in several > places. With the suggested properties, secure-vault.yaml will have all the > information it needs for the initialization. Hence it could check the mode > at one place and initialize the secure vault accordingly. > Is it possible to move the parts where we need to check if it is an OSGi mode or not to a generic place that is at the start and these values are based to the implementation later? So that the implementation layer does not need to know whether it is a OSGi or non-OSGi. > > Thanks, > Jayanga. > > *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> > > On Fri, Mar 17, 2017 at 9:43 AM, Niranjan Karunanandham <niran...@wso2.com > > wrote: > >> Hi Vidura, >> >> We can identify whether it is in OSGi mode or non-OSGi mode by checking >> if the bundleContext is set. If it is not set, then it is in non-OSGi mode. >> This is the way we have done for msf4j. Any reason for this new approach? >> >> Regards, >> Nira >> >> On Fri, Mar 17, 2017 at 9:37 AM, Lakshman Udayakantha <lakshm...@wso2.com >> > wrote: >> >>> Hi Vidura, >>> >>> 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.DefaultSecretR >>>> epository >>>> parameters: >>>> privateKeyAlias: wso2carbon >>>> keystoreLocation: resources/security/wso2carbon.jks >>>> masterKeyReader: >>>> type: org.wso2.carbon.kernel.securevault.reader.DefaultMasterKeyRe >>>> ader >>>> >>>> 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). >>>> >>> Since this happens in implementation class as in this case in Default >>> implementation, IMO it is not a problem to check whether OSGI or not to >>> give the correct file location. Even when you create another implementation >>> that should work in both OSGI and non OSGI enviorenments you have to check >>> for OSGI or not to give the correct file location. >>> >>>> >>>> >>> >>>> *Suggestion:* >>>> >>>> secretRepository: >>>> type: org.wso2.carbon.secvault.securevault.repository.DefaultSecre >>>> tRepository >>>> parameters: >>>&
Re: [Architecture] [C5] Carbon Secure Vault YAML Configuration
Hi Vidura, We can identify whether it is in OSGi mode or non-OSGi mode by checking if the bundleContext is set. If it is not set, then it is in non-OSGi mode. This is the way we have done for msf4j. Any reason for this new approach? Regards, Nira On Fri, Mar 17, 2017 at 9:37 AM, Lakshman Udayakantha <lakshm...@wso2.com> wrote: > Hi Vidura, > > 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.DefaultSecretR >> epository >> 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). >> > Since this happens in implementation class as in this case in Default > implementation, IMO it is not a problem to check whether OSGI or not to > give the correct file location. Even when you create another implementation > that should work in both OSGI and non OSGI enviorenments you have to check > for OSGI or not to give the correct file location. > >> >> > >> *Suggestion:* >> >> secretRepository: >> type: org.wso2.carbon.secvault.securevault.repository.DefaultSecre >> tRepository >> parameters: >> privateKeyAlias: wso2carbon >> keystoreLocation: securevault/resources/security/wso2carbon.jks >> secretProperties: securevault/resources/security/secrets.properties >> masterKeyReader: >> type: org.wso2.carbon.secvault.securevault.utils.DefaultHardCodedM >> asterKeyReader >> 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/> >> > > > > -- > Lakshman Udayakantha > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > Mobile: *0717429601* > > -- *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
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi Vidura, On Fri, Mar 10, 2017 at 7:27 PM, Vidura Nanayakkara <vidu...@wso2.com> wrote: > Hi All, > > We can create a tempory branch out from the master in Carbon Kernel [1] > <https://github.com/wso2/carbon-kernel>, merge Lakshman's PR to that > branch and then move it to the Carbon SecVault [2] > <https://github.com/wso2/carbon-secvault> (not the master branch - we > need to create another new branch here). This way we can we can preserve > the commit history. I will create my pull request to the new branch in > Carbon Sec Vault. > Noted. I have created a separate branch[1] in kernel and merged Lakshman's PR so that it can be moved carbon-secvault. I have create another branch[2] in carbon-secvault, so that you can move this component from kernel. > > [1] Carbon Kernel <https://github.com/wso2/carbon-kernel> > [2] Carbon Secure Vault <https://github.com/wso2/carbon-secvault> > > > On Fri, Mar 10, 2017 at 7:11 PM, Niranjan Karunanandham <niran...@wso2.com > > wrote: > >> Hi all, >> >> On Fri, Mar 10, 2017 at 6:55 PM, Lakshman Udayakantha <lakshm...@wso2.com >> > wrote: >> >>> Hi Imesh, >>> >>> On Fri, Mar 10, 2017 at 3:54 PM, Imesh Gunaratne <im...@wso2.com> wrote: >>> >>>> Hi Vidura, >>>> >>>> I think it would be better if we can first move the secure vault code >>>> from carbon-kernel repository to the new repository with commit history and >>>> then apply the changes you have done. Otherwise, we will loose all history. >>>> >>> +1 to preserve history. >>> >>>> >>>> I had a chat with Lakshman on this and it seems like he has extracted >>>> all secure-vault related code into a new component and sent a PR [1] but it >>>> has not been merged. >>>> >>>> IMO we would need to do following: >>>> >>>>- First, fix conflicts and merge [1]. This would bring all secure >>>>vault related code to a new component/folder. >>>> >>>> I have solved the conflicts and updated the PR. >>> >> I am -1 for merging this in kernel master branch because this PR is not >> complete and there were couple of changes requested for this. Lakshman had >> moved the PR to the new repo as suggested during the code review and it has >> been merged in a separate branch [1]. AFAIR we discussed that Vidura could >> continue making the fixes as suggested in the review and send the PR to the >> branch. Once it is in a done done state, we can move it to the master >> branch (this is because once a PR is merged to master branch it will be >> released since CI/CD is configured). >> >> @Imesh: +1 if we can preseve the commits from the kernel and move it to >> Carbon-secvault. (if we need to merge the PR then we can merge it in a >> separate branch. Currently the PR to kernel is sent to the master branch) >> >> @Vidura: If the commits can be preserved then please coordinate with >> Lakshman. >> >> >>> Thanks, >>> Lakshman. >>> >>>> >>>>- Then move above folder to [2] using a PR-X >>>>- Once the PR-X is merged, apply your changes on top of it. >>>> >>>> [1] https://github.com/wso2/carbon-kernel/pull/1266 >>>> [2] https://github.com/wso2/carbon-secvault >>>> >>>> Thanks >>>> >>>> On Mon, Mar 6, 2017 at 12:15 PM, Niranjan Karunanandham < >>>> niran...@wso2.com> wrote: >>>> >>>>> Hi Vidura, >>>>> >>>>> On Mon, Mar 6, 2017 at 11:52 AM, Imesh Gunaratne <im...@wso2.com> >>>>> wrote: >>>>> >>>>>> On Fri, Mar 3, 2017 at 12:00 PM, Thusitha Thilina Dayaratne < >>>>>> thusit...@wso2.com> wrote: >>>>>> >>>>>>> Rather than having a separate repo for utils I'll look into the >>>>>>> possibility of moving that to a separate component (same level as core) >>>>>>> without having cyclic dependencies. If that is possible then we can pack >>>>>>> that as a new feature or core feature itself. Otherwise lets move that >>>>>>> to a >>>>>>> separate repo. >>>>>>> >>>>>>> Thusitha has done this change in the following PR: >>>>>> https://github.com/wso2/carbon-kernel/pull/1318 >>>>>> >>>>> Once this PR is merged, we need to add the
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi all, On Fri, Mar 10, 2017 at 6:55 PM, Lakshman Udayakantha <lakshm...@wso2.com> wrote: > Hi Imesh, > > On Fri, Mar 10, 2017 at 3:54 PM, Imesh Gunaratne <im...@wso2.com> wrote: > >> Hi Vidura, >> >> I think it would be better if we can first move the secure vault code >> from carbon-kernel repository to the new repository with commit history and >> then apply the changes you have done. Otherwise, we will loose all history. >> > +1 to preserve history. > >> >> I had a chat with Lakshman on this and it seems like he has extracted all >> secure-vault related code into a new component and sent a PR [1] but it has >> not been merged. >> >> IMO we would need to do following: >> >>- First, fix conflicts and merge [1]. This would bring all secure >>vault related code to a new component/folder. >> >> I have solved the conflicts and updated the PR. > I am -1 for merging this in kernel master branch because this PR is not complete and there were couple of changes requested for this. Lakshman had moved the PR to the new repo as suggested during the code review and it has been merged in a separate branch [1]. AFAIR we discussed that Vidura could continue making the fixes as suggested in the review and send the PR to the branch. Once it is in a done done state, we can move it to the master branch (this is because once a PR is merged to master branch it will be released since CI/CD is configured). @Imesh: +1 if we can preseve the commits from the kernel and move it to Carbon-secvault. (if we need to merge the PR then we can merge it in a separate branch. Currently the PR to kernel is sent to the master branch) @Vidura: If the commits can be preserved then please coordinate with Lakshman. > Thanks, > Lakshman. > >> >>- Then move above folder to [2] using a PR-X >>- Once the PR-X is merged, apply your changes on top of it. >> >> [1] https://github.com/wso2/carbon-kernel/pull/1266 >> [2] https://github.com/wso2/carbon-secvault >> >> Thanks >> >> On Mon, Mar 6, 2017 at 12:15 PM, Niranjan Karunanandham < >> niran...@wso2.com> wrote: >> >>> Hi Vidura, >>> >>> On Mon, Mar 6, 2017 at 11:52 AM, Imesh Gunaratne <im...@wso2.com> wrote: >>> >>>> On Fri, Mar 3, 2017 at 12:00 PM, Thusitha Thilina Dayaratne < >>>> thusit...@wso2.com> wrote: >>>> >>>>> Rather than having a separate repo for utils I'll look into the >>>>> possibility of moving that to a separate component (same level as core) >>>>> without having cyclic dependencies. If that is possible then we can pack >>>>> that as a new feature or core feature itself. Otherwise lets move that to >>>>> a >>>>> separate repo. >>>>> >>>>> Thusitha has done this change in the following PR: >>>> https://github.com/wso2/carbon-kernel/pull/1318 >>>> >>> Once this PR is merged, we need to add the support to provide an API >>> which can return the current config folder for a particular runtime. >>> >>> >>>> >>>> >>>> Thanks >>>> >>>> -- >>>> *Imesh Gunaratne* >>>> Software Architect >>>> WSO2 Inc: http://wso2.com >>>> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> >>>> W: https://medium.com/@imesh TW: @imesh >>>> lean. enterprise. middleware >>>> >>>> >>> Regards, >>> Nira >>> >>> -- >>> >>> >>> *Niranjan Karunanandham* >>> Associate Technical Lead - WSO2 Inc. >>> WSO2 Inc.: http://www.wso2.com >>> >>> >> >> >> -- >> *Imesh Gunaratne* >> Software Architect >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> >> W: https://medium.com/@imesh TW: @imesh >> lean. enterprise. middleware >> >> > > > -- > Lakshman Udayakantha > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > Mobile: *0717429601* > > [1] - https://github.com/wso2/carbon-secvault/tree/move-from-kernel 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
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi Vidura, On Mon, Mar 6, 2017 at 11:52 AM, Imesh Gunaratne <im...@wso2.com> wrote: > On Fri, Mar 3, 2017 at 12:00 PM, Thusitha Thilina Dayaratne < > thusit...@wso2.com> wrote: > >> Rather than having a separate repo for utils I'll look into the >> possibility of moving that to a separate component (same level as core) >> without having cyclic dependencies. If that is possible then we can pack >> that as a new feature or core feature itself. Otherwise lets move that to a >> separate repo. >> >> Thusitha has done this change in the following PR: > https://github.com/wso2/carbon-kernel/pull/1318 > Once this PR is merged, we need to add the support to provide an API which can return the current config folder for a particular runtime. > > > Thanks > > -- > *Imesh Gunaratne* > Software Architect > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057> > W: https://medium.com/@imesh TW: @imesh > lean. enterprise. middleware > > 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
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
2/carbon-secvault>. This change will >>> not have any major impact on any of the current implementations. The only >>> change you have to make is to use the new maven dependencies and import any >>> class used from the right package. New maven dependency information >>> would be as follows for the components: >>> >>> *Carbon configuration* >>> >>> >>> org.wso2.carbon >>> org.wso2.carbon.configuration >>> 1.0.0-SNAPSHOT >>> >>> >>> *Carbon Secure Vault* >>> >>> >>> org.wso2.carbon >>> org.wso2.carbon.securevault >>> 1.0.0-SNAPSHOT >>> >>> >>> Both Carbon configuration and Carbon Secure Vault will have carbon >>> features implemented that will be installed in the Carbon Kernel. New >>> maven dependency information for the features of the above will be as >>> follows: >>> >>> *Carbon configuration Feature* >>> >>> >>> org.wso2.carbon >>> org.wso2.carbon.configuration.feature >>> 1.0.0-SNAPSHOT >>> >>> >>> *Carbon Secure Vault Feature* >>> >>> >>> org.wso2.carbon >>> org.wso2.carbon.securevault.feature >>> 1.0.0-SNAPSHOT >>> >>> >>> Furthermore, maven configuration plugin [4] will be also moved to the >>> Carbon Config [5] <https://github.com/wso2/carbon-config> repo. Carbon >>> configuration maven plugin dependency information would be as mentioned >>> below: >>> >>> >>> org.wso2.carbon >>> org.wso2.carbon.configuration.maven.plugin >>> 1.0.0-SNAPSHOT >>> >>> >>> [1] Carbon Kernel Issue >>> <https://github.com/wso2/carbon-kernel/issues/1312> >>> [2] Carbon Sec-Vault Issue >>> <https://github.com/wso2/carbon-secvault/issues/2> >>> [3] Carbon Config Issue <https://github.com/wso2/carbon-config/issues/1> >>> [4] [Architecture] Carbon C5 - Server Configuration Model >>> [5] Carbon configuration repo <https://github.com/wso2/carbon-config> >>> [6] Carbon Secvault Repo <https://github.com/wso2/carbon-secvault> >>> [7] Carbon Kernel Repo <https://github.com/wso2/carbon-kernel> >>> >>> >>> 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/> >>> >> >> >> >> -- >> 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/> >> > > > > -- > 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/> > 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
Re: [Architecture] [C5] Moving Carbon Configuration and Carbon Sec-Vault to 2 Separate Repositories (Removing from Kernel)
Hi Vidura, On Thu, Mar 2, 2017 at 6:35 PM, Vidura Nanayakkara <vidu...@wso2.com> wrote: > Hi, > > I am in the process of moving Carbon Configuration and Secure Vault from > Carbon Kernel [7] <https://github.com/wso2/carbon-config> repository. > Both these components will support OSGi mode as well as non-OSGi mode. > Following > are the reasons behind moving these into new repositories. > > Reasons for moving carbon configuration to a new repo: > >- The package is intended to provide configuration support for both >OSGi and non-OSGi components and is to be used by MSF4J (OSGI and >standalone mode), DAS etc. Therefore "org.wso2.carbon.configuration" >should be a separate independent module (not inheriting the carbon kernel's >parent pom) >- Having the package within carbon kernel could lead into problems as >having to release carbon kernel each time a change is made to >"org.wso2.carbon.configuration" > > Reasons for moving carbon sec-vault to a new repo: > >- Carbon secure vault is to be used by the Carbon Kernal. However, the >secure vault is provided via the carbon configuration module. Therefore we >decided that it would be best if secure vault is released as a separate >repository while carbon configuration module having a tight dependency to >the secure vault (Since as for the above point, we have to make >"org.wso2.carbon.configuration" a separate repository) >- If we merge secure vault configuration with deployement.yaml and if >there are cipher texts in deployment YAML, secure vault component has to >depend on config component because secure vault configs reside in >deployment YAML and config component has to depend on secure vault since we >need to unciper the cipperd values in deployment YAML, that leads to cyclic >dependency. > > According to the new structure, > > Carbon configuration will be in repo [5] > <https://github.com/wso2/carbon-config> and Carbon Secure Vault will be > in repo [6] <https://github.com/wso2/carbon-secvault>. This change will > not have any major impact on any of the current implementations. The only > change you have to make is to use the new maven dependencies and import any > class used from the right package. New maven dependency information would > be as follows for the components: > > *Carbon configuration* > > > org.wso2.carbon > org.wso2.carbon.configuration > 1.0.0-SNAPSHOT > > > *Carbon Secure Vault* > > > org.wso2.carbon > org.wso2.carbon.securevault > 1.0.0-SNAPSHOT > > > Both Carbon configuration and Carbon Secure Vault will have carbon > features implemented that will be installed in the Carbon Kernel. New > maven dependency information for the features of the above will be as > follows: > > *Carbon configuration Feature* > > > org.wso2.carbon > org.wso2.carbon.configuration.feature > 1.0.0-SNAPSHOT > > > *Carbon Secure Vault Feature* > > > org.wso2.carbon > org.wso2.carbon.securevault.feature > 1.0.0-SNAPSHOT > > > Furthermore, maven configuration plugin [4] will be also moved to the > Carbon Config [5] <https://github.com/wso2/carbon-config> repo. Carbon > configuration maven plugin dependency information would be as mentioned > below: > > > org.wso2.carbon > org.wso2.carbon.configuration.maven.plugin > 1.0.0-SNAPSHOT > > > IMO in the carbon-config feature, we need to have an importFeatureDef to Carbon-secvault since it requires secure vault feature. Therefore from the carbon-kernel and other products needs to only install carbon-config feature which will inturn bring in the Secure vault feature. > [1] Carbon Kernel Issue > <https://github.com/wso2/carbon-kernel/issues/1312> > [2] Carbon Sec-Vault Issue > <https://github.com/wso2/carbon-secvault/issues/2> > [3] Carbon Config Issue <https://github.com/wso2/carbon-config/issues/1> > [4] [Architecture] Carbon C5 - Server Configuration Model > [5] Carbon configuration repo <https://github.com/wso2/carbon-config> > [6] Carbon Secvault Repo <https://github.com/wso2/carbon-secvault> > [7] Carbon Kernel Repo <https://github.com/wso2/carbon-kernel> > > > 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/> > 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
Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template
gt;>> 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 >>>> >>>> >>> >> >> >> -- >> *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 > > 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
[Architecture] WSO2 Carbon Kernel 5.2.0-m3 Released
WSO2 Carbon Kernel 5.2.0-m3 Released The Carbon team is pleased to announce the release of Carbon Kernel 5.2.0-M2. It is now available to download from here <https://github.com/wso2/carbon-kernel/releases/tag/v5.2.0-m3>. *Improvements and Bug fixes* https://github.com/wso2/carbon-kernel/milestone/8?closed=1 *How to Contribute* WSO2 Carbon Kernel code is hosted in Github. The Git repository is https://github.com/wso2/carbon-kernel/ Carbon Kernel 5.2.0-M2 release tag is https://github.com/wso2/car bon-kernel/releases/tag/v5.2.0-m3 Please report issues at Carbon Jira: https://github.com/wso2/ carbon-kernel/issues *Contact Us* WSO2 Carbon developers can be contacted via following mailing lists: WSO2 Developers List: d...@wso2.org WSO2 Architecture List: architecture@wso2.org You can download the released distribution from the following location: https://github.com/wso2/carbon-kernel/releases Thank you for your interest in WSO2 Carbon Kernel. Best Regards Carbon Team -- *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
[Architecture] [Dev] WSO2 Carbon Feature Plugin 3.0.0 Released
*WSO2 Carbon Feature Plugin 3.0.0 Released* The Carbon team is pleased to announce the release of Carbon Feature Plugin 3.0.0. It is now available to download from here <https://github.com/wso2/carbon-maven-plugins/releases/tag/v3.0.0>. *Improvements and Bug fixes* https://wso2.org/jira/issues/?filter=13622 *Known Issues* https://github.com/wso2/carbon-maven-plugins/issues *How to Contribute* - WSO2 Carbon Feature Plugin code is hosted in Github. - The Git repository is https://github.com/wso2/carbon-maven-plugins - Carbon Feature Plugin 3.0.0 release tag is https://github.com/wso2/carbon-maven-plugins/releases/tag/v3.0.0 - Please report issues at Carbon Feature Plugin Jira, https://github.com/wso2/carbon-maven-plugins/issues *Contact Us* WSO2 Carbon developers can be contacted via following mailing lists: - WSO2 Developers List: d...@wso2.org - WSO2 Architecture List: architecture@wso2.org Best Regards Carbon Team -- *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
Re: [Architecture] Kernel changes/improvements needed for IS release
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
Re: [Architecture] Configuration files in C5
Hi Jayanga, On Thu, Oct 13, 2016 at 5:07 PM, Jayanga Dissanayake <jaya...@wso2.com> wrote: > Hi All, > > With C5, we introduced "ConfigResolver" which enhances the user experience > in changing configuration values. With the previous C4x approach, users had > to know where the configuration files are and to, change several > configuration files to get the product working in some scenarios. > > With "ConfigResolver" it allows us to have more frequently changing > configurations in one location "deployment.properties" file. > > A product has set of configurations that are needed to be changed in the > deployments and there are some other configurations that we don't change > unless there is a complex situation. Hence, ideally, deployment.properties > file should contain only the configurations that are frequently used and > can add more entries if a requirement arise. > > But with the requirements coming in with the "profile" support [1]. we > have to rethink the way config resolver handle the configuration files. > > eg: > 1. We need to enable indexing in API store and publisher, not in other > profiles. > 2. Enabling certain handlers in particular profiles. > > At present, there is no configuration to enable/disable these features. We > have to rethink the way we define configurations in features in future. We > have to have a way to enable/disable certain features so that those could > be disabled in certain profiles. > The above two examples that you have mentioned cannot be called features (please correct me if am wrong). AFAIU those are functionalities which are specific to profiles, i.e., certain features have multiple options (configurations) based on which the features functionality changes. Therefore the configurations can change from feature to feature? > > Any idea/questions/clarifications are highly appreciated as it will help > to model the new configurations story in C5. > > [1] "Multiple profile support for C5 based products." > > 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
Re: [Architecture] Fwd: Defining KeyStores in C5
Hi Susinda
On Mon, Jul 18, 2016 at 10:47 AM, Susinda Perera <susi...@wso2.com> wrote:
>
> -- Forwarded message --
> From: Jayanga Dissanayake <jaya...@wso2.com>
> Date: Fri, Jul 15, 2016 at 1:22 PM
> Subject: [Architecture] Defining KeyStores in C5
> To: Architecture List <architecture@wso2.org>
>
>
> Hi All,
>
> Currently I am redesigning the SecureVault implementation for C5. Our main
> approach is to change the current implementation in more OSGi friendly and
> extensible manner. While designing the new approach I came across the
> following manner.
>
> How are we going to define KeyStores in the C5?
>
> Is it the carbon.yml, we are going to define all the keystores or are we
> going to define keystore for secure vault separately and SSL related
> keystores in respective transports yamls.
>
> The concerns I have here are,
>
> 1. If we define all the keystores in carbon.yml, this will be a blocker
> for SecureVault initialization. Because, in the secure vault
> initialization, it has to parse the carbon.yml via “ConfigUtil” (This name
> is not yet finalized) : Dynamic Configuration Update Module , to get the
> carbon.yml updated for the Environment, System and Security related
> parameters. Hence, by the time the dynamic configuration update happens,
> SecureVault has to be initialized.
>
> So, the option would be to have a separate configuration file for
> SecureVault, which doesn't have ${sec:xyz} directives. (Hence no issue for
> SecureVault). It may have ${env:xyz} and ${sys:xyz} directives and get
> those parameters updated properly.
>
> 2. If we go with the Option:1, then we can define the SSL related
> keystores in carbon.yml, or respective transport configurations.
> Configurations of those can have all three types of dynamic configuration
> directives without any restrictions. Because by the time those components
> read the configuration, SecureVault is initialized.
>
> 3. One other option would be to expose the access to the keystores as an
> OSGi service. We can use a separate component or same SecureVaule (might
> need to change the name) component to expose that as an OSGi service. So,
> if an other component needs a Key, it could provide the alias and private
> key password to this service and get the Key and continue.
> This approach will work fine for carbon components. But if there are any
> third party components that uses keystores directly (as we had in C4,
> axis2.xml, catalina-server.xml, etc) this approach doesn't add much value.
>
> Considering above mentioned approaches, I would suggest to have,
> 1. A separate configuration file for SecureVault (name would be
> secure_vault.yml). Which will have KeyStore information related to
> encrypting and decrypting passwords.
> 2. And SSL related keystore information in respective transport
> configurations.
> +1 for separating keystores for SSL and other encryptions(secure vault),
> Currently we have KeyStore and RegistryKeyStore configs where
> RegistryKeyStore is used to encrypt the data written to registry and
> KeyStore for all other (SSL and Secure-Vault). I think we can use a
> separate keystore for SSL and another one for Secure-Vault and registry
> encryption.
> Also I think we have to consider secure vault for json, yml and any other
> file types.
>
RegistryKeystore is only there in Carbon 4.2.0 based products. From Carbon
4.4.x based products the Keystore define the carbon.xml is used for
Encrypting and Decrypting whereas the SSL keystore is defined in
catalina-server.xml.
+1 for secure vault for json and yml
>
>
> Suggestions and thoughts are welcome.
>
> Thanks,
> *Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: jaya...@wso2.com
> mobile: +94772207259
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
>
>
> --
> *Susinda Perera*
> Software Engineer
> B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL)
> Mobile:(+94)716049075
> Blog: susinda.blogspot.com
> WSO2 Inc. http://wso2.com/
> Tel : 94 11 214 5345 Fax :94 11 2145300
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
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
Re: [Architecture] [Dev] [C5] Upgrading Kernel Equinox version to Neon Releases
+1 to upgrade the tycho plugin. Currently we are using 0.13.0 and AFAIR the latest one is 0.25.0. Regards, Nira On Tue, Jul 5, 2016 at 3:11 PM, Sameera Jayasoma <same...@wso2.com> wrote: > +1 for this. > > On Tue, Jul 5, 2016 at 2:48 PM, Chanaka Cooray <chana...@wso2.com> wrote: > >> [+architecture] >> >> On Tue, Jul 5, 2016 at 1:53 PM, Chanaka Cooray <chana...@wso2.com> wrote: >> >>> Hi all, >>> >>> We have decided to upgrade the equinox version in kernel to Neon release >>> which is the latest release of the equinox[1]. This has to be done due to >>> several issues in kernel including [2] with the current equinox version. >>> Addition to that, it is also required to upgrade tycho versions in >>> carbon-maven-plugins [3] because of a jarsigner issue with the JDK 7, 8. >>> >>> [1] http://download.eclipse.org/equinox/ >>> [2] https://wso2.org/jira/browse/CARBON-15976 >>> [3] https://github.com/wso2/carbon-maven-plugins >>> >>> Thanks, >>> Chanaka. >>> -- >>> Chanaka Cooray >>> Software Engineer, WSO2 Inc. http://wso2.com >>> Email: chana...@wso2.com >>> Mobile: +94713149860 >>> >>> >> >> >> -- >> Chanaka Cooray >> Software Engineer, WSO2 Inc. http://wso2.com >> Email: chana...@wso2.com >> Mobile: +94713149860 >> >> > > > -- > 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 > > -- *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
[Architecture] [Dev] WSO2 Carbon Kernel 5.1.0 Released !!!
*WSO2 Carbon Kernel 5.1.0 - Released !!!* We are pleased to announce the release of WSO2 Carbon Kernel 5.1.0. It is now available to download from here <https://github.com/wso2/carbon-kernel/releases/download/v5.1.0/wso2carbon-kernel-5.1.0.zip>. The source and tag location for this release are available here <https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0>. WSO2 Carbon Kernel 5.1.0 is the core of the next-generation WSO2 Carbon platform. We have completely rearchitected Carbon Kernel from the ground up with the latest technologies and patterns. Additionally, the Carbon Kernel is now a lightweight, general-purpose OSGi runtime specializing in hosting servers, providing key functionality for server developers. The result is a streamlined and even more powerful middleware platform than ever before. This release of the WSO2 Carbon Kernel includes the following key features. For further details please see the documentation <https://docs.wso2.com/display/Carbon510/WSO2+Carbon+Documentation>. Key Features - Java 8 Support - Carbon Component Startup Order Resolver - Carbon Tools - Jar To Bundle Converter and Dropins Installer - Equipped with Eclipse Luna SR2 OSGi Framework - Dropins Support for OSGi Ready Bundles - Carbon Launcher - Centralized Logging Framework with Log4j 2.0 as the Backend - Transport Management - Pluggable Runtime Management - OSGi Test Framework - Audit Log Mechanism - JMX support - Carbon Context API *Fixed Issues* - WSO2 Carbon Kernel 5.1.0 - Fixed Issues <https://wso2.org/jira/issues/?filter=13077> Known Issues - WSO2 Carbon Kernel 5.1.0 - Known Issues <https://wso2.org/jira/issues/?filter=13078> How To Contribute You can find more instructions on how to contribute on our documentation <https://docs.wso2.com/display/Carbon510/Get+Involved> site. If you have any suggestions or are interested in Carbon Kernel 5.1.0 discussions, you can join the d...@wso2.org or architecture@wso2.org mailing lists. Reporting Issues We encourage you to report issues, documentation errors regarding WSO2 Carbon Kernel 5.1.0 through the public issue tracking system <https://wso2.org/jira/browse/CARBON>. Thanks, WSO2 Carbon Team -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 Carbon Kernel 5.1.0-beta Released
*WSO2 Carbon Kernel 5.1.0-beta Released* The Carbon team is pleased to announce the release of Carbon Kernel 5.1.0- beta. It is now available to download from here <https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-beta>. *Improvements and Bug fixes* https://wso2.org/jira/issues/?filter=13066 *Known Issues* *https://wso2.org/jira/issues/?filter=13067 <https://wso2.org/jira/issues/?filter=13067>* *How to Contribute* - WSO2 Carbon Kernel code is hosted in github. - The Git repository is https://github.com/wso2/carbon-kernel/ - Carbon Kernel 5.1.0-beta release tag is https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-beta <https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-beta> - Please report issues at Carbon Jira, https://wso2.org/jira/browse/CARBON *Contact Us * WSO2 Carbon developers can be contacted via following mailing lists: - WSO2 Developers List: d...@wso2.org - WSO2 Architecture List: architecture@wso2.org You can download the released distribution from the following location. http://wso2.com/products/carbon/ Thank you for your interest in WSO2 Carbon Kernel. Best Regards Carbon Team -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ 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
Hi Pulasthi, Did you add the feature to the p2-repo generation section in the pom? Can you check if the feature is there in your p2-repo? Regards, Nira On Fri, May 20, 2016 at 2:46 PM, Pulasthi Mahawithana <pulast...@wso2.com> wrote: > Hi Niranjan, > > It was failing with the p2 repo that is created in p2-profile-gen. > Looking at the pom at [1], this feature only imports the org.wso2.carbon.core > which is available in IS but as a different patch release version. Does the > difference in the patch release version matter here? Or is it due to > something else? > > [1] > https://github.com/wso2/carbon-analytics-common/blob/v5.0.11/features/event-publisher/org.wso2.carbon.event.publisher.aggregate.feature/pom.xml > > On Fri, May 20, 2016 at 2:10 PM, Niranjan Karunanandham <niran...@wso2.com > > wrote: > >> Hi Pulasthi, >> >> When building the product, are you referring to the p2-repo of the >> locally built carbon-feature-repository or to a p2-repo that you create in >> p2-profile-gen. If so this issue can happen if the feature that you are >> installing has import features which are not there in your p2-repo. >> >> @Malith: As per the previous mail, can you close this PR since it need to >> come from the PR from the product team which will be using the feature. >> >> Regards, >> Nira >> >> Regards, >> Nira >> >> On Fri, May 20, 2016 at 12:47 PM, Pulasthi Mahawithana < >> pulast...@wso2.com> wrote: >> >>> I tried to add this feature to product-is 's p2-profile-gen. But it >>> fails saying, >>> >>> Installation failed. >>> The installable unit >>> org.wso2.carbon.event.publisher.aggregate.feature.group/5.0.11 has not been >>> found. >>> >>> However I can install it from feature management UI when I merged and >>> built the carbon feature repository locally with the PR at [1] and point >>> that as a local repository. Any possible causes for this? >>> >>> [1] https://github.com/wso2/carbon-feature-repository/pull/46 >>> >>> On Wed, Apr 27, 2016 at 9:08 AM, Niranjan Karunanandham < >>> niran...@wso2.com> wrote: >>> >>>> Hi Malith, >>>> >>>> Since this feature will be included in the next ESB release, IMO it >>>> would be better to close the current PR and have it included in the same PR >>>> after the product release. >>>> >>>> Regards, >>>> Nira >>>> >>>> On Mon, Apr 25, 2016 at 6:05 PM, Malith Dhanushka <mal...@wso2.com> >>>> wrote: >>>> >>>>> Hi Niranjan, >>>>> >>>>> Correction on my previous reply. we have to ship this feature by >>>>> default with ESB and APIM. So this needs to be released with the immediate >>>>> ESB or APIM release. >>>>> >>>>> @Viraj - Please include this feature in next ESB release. I have >>>>> already sent a pull request by including this to >>>>> carbon-feature-repository. >>>>> >>>>> Thanks, >>>>> Malith >>>>> >>>>> On Mon, Apr 25, 2016 at 5:44 PM, Malith Dhanushka <mal...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi Niranjan, >>>>>> >>>>>> Since this feature doesn't ship by default in any of the products, >>>>>> please go ahead and merge this as an special case. >>>>>> >>>>>> Thanks, >>>>>> Malith >>>>>> >>>>>> On Tue, Apr 12, 2016 at 10:56 AM, Niranjan Karunanandham < >>>>>> niran...@wso2.com> wrote: >>>>>> >>>>>>> Hi Malith, >>>>>>> >>>>>>> On Fri, Mar 18, 2016 at 11:42 AM, Malith Dhanushka <mal...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Mar 18, 2016 at 11:38 AM, Kishanthan Thangarajah < >>>>>>>> kishant...@wso2.com> wrote: >>>>>>>> >>>>>>>>> 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? >>>&
Re: [Architecture] [Dev] Common configuration for publishing events from carbon servers to DAS/CEP
Hi Pulasthi, When building the product, are you referring to the p2-repo of the locally built carbon-feature-repository or to a p2-repo that you create in p2-profile-gen. If so this issue can happen if the feature that you are installing has import features which are not there in your p2-repo. @Malith: As per the previous mail, can you close this PR since it need to come from the PR from the product team which will be using the feature. Regards, Nira Regards, Nira On Fri, May 20, 2016 at 12:47 PM, Pulasthi Mahawithana <pulast...@wso2.com> wrote: > I tried to add this feature to product-is 's p2-profile-gen. But it fails > saying, > > Installation failed. > The installable unit > org.wso2.carbon.event.publisher.aggregate.feature.group/5.0.11 has not been > found. > > However I can install it from feature management UI when I merged and > built the carbon feature repository locally with the PR at [1] and point > that as a local repository. Any possible causes for this? > > [1] https://github.com/wso2/carbon-feature-repository/pull/46 > > On Wed, Apr 27, 2016 at 9:08 AM, Niranjan Karunanandham <niran...@wso2.com > > wrote: > >> Hi Malith, >> >> Since this feature will be included in the next ESB release, IMO it would >> be better to close the current PR and have it included in the same PR after >> the product release. >> >> Regards, >> Nira >> >> On Mon, Apr 25, 2016 at 6:05 PM, Malith Dhanushka <mal...@wso2.com> >> wrote: >> >>> Hi Niranjan, >>> >>> Correction on my previous reply. we have to ship this feature by default >>> with ESB and APIM. So this needs to be released with the immediate ESB or >>> APIM release. >>> >>> @Viraj - Please include this feature in next ESB release. I have already >>> sent a pull request by including this to carbon-feature-repository. >>> >>> Thanks, >>> Malith >>> >>> On Mon, Apr 25, 2016 at 5:44 PM, Malith Dhanushka <mal...@wso2.com> >>> wrote: >>> >>>> Hi Niranjan, >>>> >>>> Since this feature doesn't ship by default in any of the products, >>>> please go ahead and merge this as an special case. >>>> >>>> Thanks, >>>> Malith >>>> >>>> On Tue, Apr 12, 2016 at 10:56 AM, Niranjan Karunanandham < >>>> niran...@wso2.com> wrote: >>>> >>>>> Hi Malith, >>>>> >>>>> On Fri, Mar 18, 2016 at 11:42 AM, Malith Dhanushka <mal...@wso2.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 18, 2016 at 11:38 AM, Kishanthan Thangarajah < >>>>>> kishant...@wso2.com> wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>> >>>>>> Yes this new change is only for OSGi based servers and no change in >>>>>> standalone data publishing API's. >>>>>> >>>>>> >>>>>>> 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/events
Re: [Architecture] Introducing Secure-Vault support to C5
n:* >> >>1. We have removed the usage of cipher-tool.properties file. (This >>file was used to keep the alias, the location to the configuration file, >>and the xpath to the secret element in the configuration file). >>2. We can support any format of configuration file with this model as >>we only care about the secret-key that we define in the >> *secrets*.properties >>file and do not depend on the xpath to find the location of the secret >>element. >> >> Thanks, >> Nipuni >> >> -- >> Nipuni Perera >> Software Engineer; WSO2 Inc.; http://wso2.com >> Email: nip...@wso2.com >> Git hub profile: https://github.com/nipuni >> Blog : http://nipunipererablog.blogspot.com/ >> Mobile: +94 (71) 5626680 >> <http://wso2.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 > > Regards, Nira -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 Carbon Kernel 5.1.0-alpha2 Released
*WSO2 Carbon Kernel 5.1.0-alpha2 Released* The Carbon team is pleased to announce the release of Carbon Kernel 5.1.0-alpha2. It is now available to download from here <https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-alpha2>. *Improvements and Bug fixes* https://wso2.org/jira/issues/?filter=13058 *Known Issues* https://wso2.org/jira/issues/?filter=13059 *How to Contribute* - WSO2 Carbon Kernel code is hosted in github. - The Git repository is https://github.com/wso2/carbon-kernel/ - Carbon Kernel 5.1.0-alpha2 release tag is https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-alpha2 - Please report issues at Carbon Jira, https://wso2.org/jira/browse/CARBON *Contact Us * WSO2 Carbon developers can be contacted via following mailing lists: - WSO2 Developers List: d...@wso2.org - WSO2 Architecture List: architecture@wso2.org You can download the released distribution from the following location. http://wso2.com/products/carbon/ Thank you for your interest in WSO2 Carbon Kernel. Best Regards Carbon Team -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ 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
Hi Malith,
Since this feature will be included in the next ESB release, IMO it would
be better to close the current PR and have it included in the same PR after
the product release.
Regards,
Nira
On Mon, Apr 25, 2016 at 6:05 PM, Malith Dhanushka <mal...@wso2.com> wrote:
> Hi Niranjan,
>
> Correction on my previous reply. we have to ship this feature by default
> with ESB and APIM. So this needs to be released with the immediate ESB or
> APIM release.
>
> @Viraj - Please include this feature in next ESB release. I have already
> sent a pull request by including this to carbon-feature-repository.
>
> Thanks,
> Malith
>
> On Mon, Apr 25, 2016 at 5:44 PM, Malith Dhanushka <mal...@wso2.com> wrote:
>
>> Hi Niranjan,
>>
>> Since this feature doesn't ship by default in any of the products, please
>> go ahead and merge this as an special case.
>>
>> Thanks,
>> Malith
>>
>> On Tue, Apr 12, 2016 at 10:56 AM, Niranjan Karunanandham <
>> niran...@wso2.com> wrote:
>>
>>> Hi Malith,
>>>
>>> On Fri, Mar 18, 2016 at 11:42 AM, Malith Dhanushka <mal...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Mar 18, 2016 at 11:38 AM, Kishanthan Thangarajah <
>>>> kishant...@wso2.com> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Yes this new change is only for OSGi based servers and no change in
>>>> standalone data publishing API's.
>>>>
>>>>
>>>>> 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,
>>>>>>
>>>>>>
>>>>>> >>>>> xmlns="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.
>>>>>>
>>>>> Usually features are added to the p2-repo (carbon-feature-repository
>>> repo) when products are re
[Architecture] WSO2 Carbon Kernel 5.1.0-alpha Released
*WSO2 Carbon Kernel 5.1.0-alpha Released* The Carbon team is pleased to announce the release of Carbon Kernel 5.1.0-alpha. It is now available to download from here <https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-alpha>. *Improvements and Bug fixes* https://wso2.org/jira/issues/?filter=13024 *Known Issues* https://wso2.org/jira/issues/?filter=13025 *How to Contribute* - WSO2 Carbon Kernel code is hosted in github. - The Git repository is https://github.com/wso2/carbon-kernel/ - Carbon Kernel 5.1.0-alpha release tag is https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-alpha - Please report issues at Carbon Jira, https://wso2.org/jira/browse/CARBON *Contact Us * WSO2 Carbon developers can be contacted via following mailing lists: - WSO2 Developers List: d...@wso2.org - WSO2 Architecture List: architecture@wso2.org You can download the released distribution from the following location. http://wso2.com/products/carbon/ Thank you for your interest in WSO2 Carbon Kernel. Best Regards Carbon Team -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ 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
Hi Malith,
On Fri, Mar 18, 2016 at 11:42 AM, Malith Dhanushka <mal...@wso2.com> wrote:
>
>
> On Fri, Mar 18, 2016 at 11:38 AM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> 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.
>>
>
> Yes this new change is only for OSGi based servers and no change in
> standalone data publishing API's.
>
>
>> 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,
>>>
>>>
>>> >> xmlns="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.
>>>
>> Usually features are added to the p2-repo (carbon-feature-repository
repo) when products are released. The product team has to send a PR of all
the features they are using in the product (from the p2-profile-gen pom).
Therefore this feature should come from the PR from the products which are
using this feature when the product is released.
>
>>> [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>*
>>
>
>
>
> --
> Malith Dhanushka
> Senior Software Engineer - Data Technologies
> *WSO2, Inc. : wso2.com <http://wso2.com/>*
> *Mobile* : +94 716 506 693
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
Regards,
Nira
--
*Niranjan Karunanandham*
Senior Software Engineer - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 Carbon Feature Plugin 2.0.1 Released
*WSO2 Carbon Feature Plugin 2.0.1 Released* The Carbon team is pleased to announce the release of Carbon Feature Plugin 2.0.1. It is now available to download from here <https://github.com/wso2/carbon-maven-plugins/releases/tag/v2.0.1>. *Improvements and Bug fixes* https://wso2.org/jira/issues/?filter=13021 *Known Issues* https://wso2.org/jira/issues/?filter=13022 *How to Contribute* - WSO2 Carbon Feature Plugin code is hosted in github. - The Git repository is https://github.com/wso2/carbon-maven-plugins - Carbon Feature Plugin 2.0.1 release tag is https://github.com/wso2/carbon-maven-plugins/releases/tag/v2.0.1 - Please report issues at Carbon Feature Plugin Jira, https://wso2.org/jira/browse/CMVNPLG <https://wso2.org/jira/browse/CMVNPLG> *Contact Us * WSO2 Carbon developers can be contacted via following mailing lists: - WSO2 Developers List: d...@wso2.org - WSO2 Architecture List: architecture@wso2.org Best Regards Carbon Team -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 Carbon Kernel 5.1.0-M3 Released
*WSO2 Carbon Kernel 5.1.0-M3 Released* The Carbon team is pleased to announce the release of Carbon Kernel 5.1.0-M3. It is now available to download from here <https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-m3>. *Improvements and Bug fixes* https://wso2.org/jira/issues/?filter=13010 *Known Issues* https://wso2.org/jira/issues/?filter=13009 *How to Contribute* - WSO2 Carbon Kernel code is hosted in github. - The Git repository is https://github.com/wso2/carbon-kernel/ - Carbon Kernel 5.1.0-M3 release tag is https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-m3 - Please report issues at Carbon Jira, https://wso2.org/jira/browse/CARBON *Contact Us * WSO2 Carbon developers can be contacted via following mailing lists: - WSO2 Developers List: d...@wso2.org - WSO2 Architecture List: architecture@wso2.org You can download the released distribution from the following location. http://wso2.com/products/carbon/ Thank you for your interest in WSO2 Carbon Kernel. Best Regards Carbon Team -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 Carbon Kernel 5.1.0-M2 Released
*WSO2 Carbon Kernel 5.1.0-M2 Released* The Carbon team is pleased to announce the release of Carbon Kernel 5.1.0-M2. It is now available to download from here <https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-m2>. *Improvements and Bug fixes* https://wso2.org/jira/issues/?filter=13006 *Known Issues* https://wso2.org/jira/issues/?filter=13008 *How to Contribute* - WSO2 Carbon Kernel code is hosted in github. - The Git repository is https://github.com/wso2/carbon-kernel/ - Carbon Kernel 5.1.0-M2 release tag is https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-m2 <https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-m2> - Please report issues at Carbon Jira, https://wso2.org/jira/browse/CARBON *Contact Us * WSO2 Carbon developers can be contacted via following mailing lists: - WSO2 Developers List: d...@wso2.org - WSO2 Architecture List: architecture@wso2.org You can download the released distribution from the following location. http://wso2.com/products/carbon/ Thank you for your interest in WSO2 Carbon Kernel. Best Regards Carbon Team -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 Carbon Kernel 5.1.0-M1 Released
*WSO2 Carbon Kernel 5.1.0-M1 Released* The Carbon team is pleased to announce the release of Carbon Kernel 5.1.0-M1. It is now available to download from here <https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-m1>. *Improvements and Bug fixes* https://wso2.org/jira/issues/?filter=12989 *Known Issues* https://wso2.org/jira/issues/?filter=12990 *How to Contribute* - WSO2 Carbon Kernel code is hosted in github. - The Git repository is https://github.com/wso2/carbon-kernel/ - Carbon Kernel 5.1.0-M1 release tag is https://github.com/wso2/carbon-kernel/releases/tag/v5.1.0-m1 - Please report issues at Carbon Jira, https://wso2.org/jira/browse/CARBON *Contact Us * WSO2 Carbon developers can be contacted via following mailing lists: - WSO2 Developers List: d...@wso2.org - WSO2 Architecture List: architecture@wso2.org You can download the released distribution from the following location. http://wso2.com/products/carbon/ Thank you for your interest in WSO2 Carbon Kernel. Best Regards Carbon Team -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 Carbon Kernel 4.4.5 Released
*WSO2 Carbon Kernel 4.4.5 Released* The Carbon team is pleased to announce the release of Carbon Kernel 4.4.5. *Improvements and Bug fixes* https://wso2.org/jira/issues/?filter=12978 *Known Issues* https://wso2.org/jira/issues/?filter=12979 *How to Contribute* - WSO2 Carbon Kernel code is hosted in github. - The Git repository is https://github.com/wso2/carbon-kernel/ - Carbon Kernel 4.4.5 release tag is https://github.com/wso2/carbon-kernel/releases/tag/v4.4.5 - Please report issues at Carbon Jira, https://wso2.org/jira/browse/ CARBON *Contact Us * WSO2 Carbon developers can be contacted via following mailing lists: - WSO2 Developers List: d...@wso2.org - WSO2 Architecture List: architecture@wso2.org You can download the released distribution from the following location. http://wso2.com/products/carbon/ Thank you for your interest in WSO2 Carbon Kernel. Best Regards Carbon Team -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Web Profile support on AS 6.0.0
Hi all, -1 for the first approach since there exists TomEE distribution. +1 for a single distribution. Regards, Nira On Wed, Feb 10, 2016 at 12:38 PM, Supun Malinga <sup...@wso2.com> wrote: > We should have a single distribution, but add the tomee jars as a runtime > environment as we had previously. > > Supun Malinga > Sent from mobile. > On Feb 10, 2016 11:36 AM, "Afkham Azeez" <az...@wso2.com> wrote: > >> Better to have one distribution. >> >> On Wed, Feb 10, 2016 at 11:31 AM, Manoj Kumara <ma...@wso2.com> wrote: >> >>> Hi All, >>> >>> On Carbon 4.x.x era to support Web profiles we have implemented a >>> ServerListener on top of Carbonized Tomcat. Further when introducing Tomcat >>> based features to Carbon servers we had to do lot of work in order to get >>> the support and this added overhead on maintaining as well. >>> >>> On future releases we are planing to use vanilla Tomcat servers with >>> added extensions to support additional features required by Carbon servers >>> (ex: SSO, Class loading, analytics etc.) to simplify the internals and to >>> be align with the latest Tomcat releases. >>> >>> I'm currently working on $Subject task and when it comes to Web Profile >>> support we can choose few approaches as I can see, >>> >>>1. Include TomEE based libs on Tomcat server to get the WebProfile >>>support (IMO approach is not suitable as that is what TomEE project is >>>trying to address the overhead of adding customized features on top of >>>Tomcat) >>>2. Use TomEE Jax-RS distribution instead of Tomcat such that with >>>single distribution we'll have features of both Tomcat and TomEE >>>3. Create two flavours of WSO2 AS 6.0.0 one with Tomcat and another >>>with TomEE Jax-RS. So depending on the requirement customers can choose >>>which distribution to use. >>> >>> As per my understanding I prefer the 3nd approach as that way use can >>> choose which variance he want depending on the requirements. >>> >>> Appreciate your feedback on this. >>> >>> Regards, >>> Manoj >>> >>> >>> >> >> >> -- >> *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 >> >> > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] P2 Repository for Carbon 4.4.X based products
Hi all, Please refer mail [1] and [2] with regard to feature categories (Nested Categories). [1] - Releasing carbon 4.4.1 p2-repo with APIM features [2] - Invitation: Releasing carbon 4.4.1 p2-repo with APIM features ASAP @ Wed Sep 2, 2015 10:30am - 11:30am (waru...@wso2.com) Regards, Nira On Tue, Jul 28, 2015 at 6:10 PM, Malaka Silva <mal...@wso2.com> wrote: > Thx Niranjan Will do. > > On Tue, Jul 28, 2015 at 4:32 PM, Niranjan Karunanandham <niran...@wso2.com > > wrote: > >> Hi Malaka, >> >> We are still in discussing the structure for the Nested Categories. As >> per the offline discussion I had with sameera, I have created the pom.xml >> [1] which has the features that AS uses (without Nested Categories). You >> can add the ESB features to it. >> >> [1] - https://github.com/wso2/carbon-feature-repository >> >> Regards, >> Nira >> >> On Tue, Jul 28, 2015 at 11:19 AM, Malaka Silva <mal...@wso2.com> wrote: >> >>> According to the offline discussion I had with carbon team they are in >>> the process of discussing this internally. >>> >>> @Carbon Team/Niranjan - We are planning to release ESB 4.9.0 beta by >>> this Thursday. Can we get it before that pls? >>> >>> On Tue, Jul 28, 2015 at 10:11 AM, Kasun Indrasiri <ka...@wso2.com> >>> wrote: >>> >>>> Do we have the doc available now? We need to test the ESB with p2-repo >>>> before the beta release. >>>> >>>> @Malaka : Can you please work with the kernel team to get this done. >>>> >>>> On Fri, Jul 17, 2015 at 4:55 PM, Niranjan Karunanandham < >>>> niran...@wso2.com> wrote: >>>> >>>>> Hi Chanaka, >>>>> >>>>> For the p2 repo, we already have the carbon-feature-repository [1], >>>>> which will have all the features in the main pom.xml. We had a review [2] >>>>> with regard to this and during the review it was suggested whether we need >>>>> to have the nested-categories within the product or should it be >>>>> platform-wise and be mentioned in the carbon-feature-repository. >>>>> Sample of the above to are available in [3] and [4]. I will be sending an >>>>> invite with regard to this on Tuesday to all the product leads to discuss >>>>> finalize whether we are going to have the nested-categories within the >>>>> product or should it be platform-wise and mentioned in >>>>> carbon-feature-repository. >>>>> >>>>> [1] - https://github.com/wso2/carbon-feature-repository >>>>> [2] - Invitation: Discussion on Categories in AS and Feature Categories >>>>> @ Thu Jun 4, 2015 11am - 12pm (niran...@wso2.com) >>>>> [3] - https://github.com/Niranjan-K/carbon-feature-repository >>>>> [4] - https://github.com/Niranjan-K/carbon-feature-repository >>>>> /tree/nested-categories >>>>> >>>>> Regards, >>>>> Nira >>>>> >>>>> >>>>> On Fri, Jul 17, 2015 at 2:57 PM, Chanaka Fernando <chana...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Since we have not released a single product with Carbon 4.4.X >>>>>> version, we need to think about creating a P2 repository for the products >>>>>> which are going to be released with the same carbon version. What should >>>>>> be >>>>>> the methodology to create a P2 repository for ESB 4.9.0 version which is >>>>>> based on the carbon 4.4.X? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Chanaka >>>>>> >>>>>> -- >>>>>> -- >>>>>> Chanaka Fernando >>>>>> Senior Technical Lead >>>>>> WSO2, Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> mobile: +94 773337238 >>>>>> Blog : http://soatutorials.blogspot.com >>>>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>>>>> Twitter:https://twitter.com/chanakaudaya >>>>>> Wordpress:http://chanakaudaya.wordpress.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ___ >>>>>> Architecture
Re: [Architecture] P2 Repository for Carbon 4.4.X based products
Hi Malaka, We are still in discussing the structure for the Nested Categories. As per the offline discussion I had with sameera, I have created the pom.xml [1] which has the features that AS uses (without Nested Categories). You can add the ESB features to it. [1] - https://github.com/wso2/carbon-feature-repository Regards, Nira On Tue, Jul 28, 2015 at 11:19 AM, Malaka Silva mal...@wso2.com wrote: According to the offline discussion I had with carbon team they are in the process of discussing this internally. @Carbon Team/Niranjan - We are planning to release ESB 4.9.0 beta by this Thursday. Can we get it before that pls? On Tue, Jul 28, 2015 at 10:11 AM, Kasun Indrasiri ka...@wso2.com wrote: Do we have the doc available now? We need to test the ESB with p2-repo before the beta release. @Malaka : Can you please work with the kernel team to get this done. On Fri, Jul 17, 2015 at 4:55 PM, Niranjan Karunanandham niran...@wso2.com wrote: Hi Chanaka, For the p2 repo, we already have the carbon-feature-repository [1], which will have all the features in the main pom.xml. We had a review [2] with regard to this and during the review it was suggested whether we need to have the nested-categories within the product or should it be platform-wise and be mentioned in the carbon-feature-repository. Sample of the above to are available in [3] and [4]. I will be sending an invite with regard to this on Tuesday to all the product leads to discuss finalize whether we are going to have the nested-categories within the product or should it be platform-wise and mentioned in carbon-feature-repository. [1] - https://github.com/wso2/carbon-feature-repository [2] - Invitation: Discussion on Categories in AS and Feature Categories @ Thu Jun 4, 2015 11am - 12pm (niran...@wso2.com) [3] - https://github.com/Niranjan-K/carbon-feature-repository [4] - https://github.com/Niranjan-K/carbon-feature-repository /tree/nested-categories Regards, Nira On Fri, Jul 17, 2015 at 2:57 PM, Chanaka Fernando chana...@wso2.com wrote: Hi All, Since we have not released a single product with Carbon 4.4.X version, we need to think about creating a P2 repository for the products which are going to be released with the same carbon version. What should be the methodology to create a P2 repository for ESB 4.9.0 version which is based on the carbon 4.4.X? Thanks, Chanaka -- -- Chanaka Fernando Senior Technical Lead WSO2, Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 773337238 Blog : http://soatutorials.blogspot.com LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 Twitter:https://twitter.com/chanakaudaya Wordpress:http://chanakaudaya.wordpress.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/ -- Best Regards, Malaka Silva Senior Tech Lead M: +94 777 219 791 Tel : 94 11 214 5345 Fax :94 11 2145300 Skype : malaka.sampath.silva LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 Blog : http://mrmalakasilva.blogspot.com/ WSO2, Inc. lean . enterprise . middleware http://www.wso2.com/ http://www.wso2.com/about/team/malaka-silva/ http://wso2.com/about/team/malaka-silva/ Save a tree -Conserve nature Save the world for your future. Print this email only if it is absolutely necessary. -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] P2 Repository for Carbon 4.4.X based products
Hi Chanaka, For the p2 repo, we already have the carbon-feature-repository [1], which will have all the features in the main pom.xml. We had a review [2] with regard to this and during the review it was suggested whether we need to have the nested-categories within the product or should it be platform-wise and be mentioned in the carbon-feature-repository. Sample of the above to are available in [3] and [4]. I will be sending an invite with regard to this on Tuesday to all the product leads to discuss finalize whether we are going to have the nested-categories within the product or should it be platform-wise and mentioned in carbon-feature-repository. [1] - https://github.com/wso2/carbon-feature-repository [2] - Invitation: Discussion on Categories in AS and Feature Categories @ Thu Jun 4, 2015 11am - 12pm (niran...@wso2.com) [3] - https://github.com/Niranjan-K/carbon-feature-repository [4] - https://github.com/Niranjan-K/carbon-feature-repository /tree/nested-categories Regards, Nira On Fri, Jul 17, 2015 at 2:57 PM, Chanaka Fernando chana...@wso2.com wrote: Hi All, Since we have not released a single product with Carbon 4.4.X version, we need to think about creating a P2 repository for the products which are going to be released with the same carbon version. What should be the methodology to create a P2 repository for ESB 4.9.0 version which is based on the carbon 4.4.X? Thanks, Chanaka -- -- Chanaka Fernando Senior Technical Lead WSO2, Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 773337238 Blog : http://soatutorials.blogspot.com LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 Twitter:https://twitter.com/chanakaudaya Wordpress:http://chanakaudaya.wordpress.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Invitation: CDM Hackathon @ Mon Dec 1, 2014 1:30pm - 5:30pm (Sameera Perera)
parity with EMM 1.1. It will be written specifically with the knowledge that platform bundles for Android, iOS are available. - The MDM will define a common set of features that are available across all phones. By introducing this layer of abstraction we are able to keep manage mobile devices across mobile platforms as we've done in EMM without complicating the device agnostic capabilities of the core. Similar modules can be built by 3rd parties to manage other device categories such as thermostats, smart TVs etc. from different vendors/platforms. *Other notes* - We have demoted the following concepts to second class citizens and pulled them out of the core 1. OS Platform, version 2. Device Platform, version 3. Roles 1 and 2 only matter to the extend that they help us define a set of available features. Bundles will be responsible for managing this set based on these factors. The core will only be aware of the set. Roles were used in the EMM only to select the policy to apply on a user's device. We have moved this responsibility to the Trigger (or handler) chain. The core will only be aware of the chain, not what logic is applied to generate the policy. *For further discussions:* - More discussion around Trigger concept - Policy merging - Feature permissions [1] Proposed Architecture of CDM - architecture@ On Tue, Dec 2, 2014 at 10:10 AM, Asok Perera as...@wso2.com wrote: Hi All, Please find the meeting minutes for the yesterday meeting. *Attendees* : Sameera Perera, Kasun Dananjaya, Prabath Abeysekera, Asok Perera, Afkham Azeez, Geeth Munasinghe, Inosh Perera, Harshan Liyanage, Niranjan Karunanandham, Sumedha Rubasinghe, Srinath Perera, Manoj Dilshan - Knowledge transfer of the current EMM architecture - Moving all the device specific entries from Core EER to bundles (bundles will have their own EERs) - Checked the possibility of separating Mobile phone devices implementation from IoT as too much generalisation seems to make the architecture too complex (Not finalised yet) - Checked the possibility of moving device specific feature information to bundles, and keeping only the definition of features in core for managing policy information (Not finalised yet) - generalising core EER by removing/moving entries like IMEI, MAC etc - Checked the possibility of renaming some entries(role, policy, feature etc) according to the standard Kindly append if I have missed anything here. Regards *Asok Aravinda Perera* Software Engineer WSO2, Inc.;http://wso2.com/ http://www.google.com/url?q=http%3A%2F%2Fwso2.com%2Fsa=Dsntz=1usg=AFQjCNGJuLRux6KkJwXKVUCYOtEsNCmIAQ lean.enterprise.middleware Mobile: +94722241032 On Mon, Dec 1, 2014 at 12:25 PM, Sameera Perera samee...@wso2.com wrote: more details » https://www.google.com/calendar/event?action=VIEWeid=cjdjYmFnamZjdWY5dTFqYTEzdm5ibDlzaDAgZW5naW5lZXJpbmctZ3JvdXBAd3NvMi5jb20tok=MTcjc2FtZWVyYXBAd3NvMi5jb201OTJhZGJmZWMzM2Q4NmViNDczZWFiYzRmNzYyZTFhOTk4MjFhMWJjctz=Asia/Colombohl=en CDM Hackathon *When* Mon Dec 1, 2014 1:30pm – 5:30pm Colombo *Where* LK 3rd Floor Meeting Room - Kernel (map https://maps.google.lk/maps?q=LK+3rd+Floor+Meeting+Room+-+Kernelhl=en ) *Video call* https://plus.google.com/hangouts/_/wso2.com/cdm-hackathon https://plus.google.com/hangouts/_/wso2.com/cdm-hackathon?hceid=c2FtZWVyYXBAd3NvMi5jb20.r7cbagjfcuf9u1ja13vnbl9sh0 *Calendar* Sameera Perera *Who* • Sameera Perera - organizer • Kasun Dananjaya Delgolla • Prabath Abeysekera • Asok Perera • Dulitha Wijewantha • Afkham Azeez • Dilan Udara Ariyaratne • Geeth Munasinghe • Inosh Perera • Harshan Liyanage • Dilshan Edirisuriya • Niranjan Karunanandham • Sumedha Rubasinghe • Srinath Perera • WSO2 Engineering Group Going? *Yes https://www.google.com/calendar/event?action=RESPONDeid=cjdjYmFnamZjdWY5dTFqYTEzdm5ibDlzaDAgZW5naW5lZXJpbmctZ3JvdXBAd3NvMi5jb20rst=1tok=MTcjc2FtZWVyYXBAd3NvMi5jb201OTJhZGJmZWMzM2Q4NmViNDczZWFiYzRmNzYyZTFhOTk4MjFhMWJjctz=Asia/Colombohl=en - Maybe https://www.google.com/calendar/event?action=RESPONDeid=cjdjYmFnamZjdWY5dTFqYTEzdm5ibDlzaDAgZW5naW5lZXJpbmctZ3JvdXBAd3NvMi5jb20rst=3tok=MTcjc2FtZWVyYXBAd3NvMi5jb201OTJhZGJmZWMzM2Q4NmViNDczZWFiYzRmNzYyZTFhOTk4MjFhMWJjctz=Asia/Colombohl=en - No https://www.google.com/calendar/event?action=RESPONDeid=cjdjYmFnamZjdWY5dTFqYTEzdm5ibDlzaDAgZW5naW5lZXJpbmctZ3JvdXBAd3NvMi5jb20rst=2tok=MTcjc2FtZWVyYXBAd3NvMi5jb201OTJhZGJmZWMzM2Q4NmViNDczZWFiYzRmNzYyZTFhOTk4MjFhMWJjctz=Asia/Colombohl=en* more options » https://www.google.com/calendar/event?action=VIEWeid=cjdjYmFnamZjdWY5dTFqYTEzdm5ibDlzaDAgZW5naW5lZXJpbmctZ3JvdXBAd3NvMi5jb20tok=MTcjc2FtZWVyYXBAd3NvMi5jb201OTJhZGJmZWMzM2Q4NmViNDczZWFiYzRmNzYyZTFhOTk4MjFhMWJjctz=Asia/Colombohl=en Invitation from Google Calendar https://www.google.com/calendar/ You are receiving this courtesy email
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Dilan, In the case of iOS, it has the MDM in its OS and they have defined the payload structure for each operation. Whereas in the case of Android, we have an agent in the client side to perform the MDM operation. I believe (please correct me if am wrong) that for windows also it is the same case as iOS. Regards, Nira On 22 Nov 2014 22:41, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Sameera, I am not exactly getting the point. It should be because I am not exactly aware of the actual use case of Windows and iOS. Do you mean that they are using different transport (or connectivity) protocols? Regards. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Sat, Nov 22, 2014 at 9:29 PM, Sameera Perera samee...@wso2.com wrote: Hi Dilan On Windows and iOS we need to use the specific protocols and rely on the OS to execute the command. This is why we have to use this approach. (Sent from a mobile device) On 22 Nov 2014 19:29, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, Why do we need to construct a Platform-specific-payload at the server level? Cannot we just send the Platform-independent-payload to the device agent and invoke the corresponding feature operation at the client side? I might not be right because I am not exactly aware of all the use-cases. Appreciate if some valid use-cases can be provided on this regard. Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage hars...@wso2.com wrote: Hi Dilan, Yes. you are correct. Thanks, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to deliver multiple payloads that might introduce an additional overhead in network. In such situations what I suggest is to merge the new payload with the existing payload. To do that we have two options. 1. Use the existing *platform-specific payload * merge it with the new operation request 2. Use the *platform-independent *form merge it with new operation request (platform-independent form) construct a new payload Going through the 1st approach will be harder because then the device-platform bundle will have to have the all the conversion logic need to convert payloads ( *platform-independent - platform-specific * *platform-specific - platform-independent). *In some platforms converting back the
Re: [Architecture] Proposed Device Operations Flow of CDM
___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Priority for Roles
Hi Prabath / Johann In EMM, the Administrator can create policies (rule) which contains a set of operations such as Wifi settings, Password policy, Camera (disable / enable), etc., and assign it to a resource. Currently the resources are Users, Platform (Android / iOS) and Roles. Devices (i.e., currently mobile devices) fall into the resources. The issue here is that when a particular device is in multiple resources which have different policies (rules) assigned to it. In that case the EMM system need to assign a single policy to a device or merge the policies to create a new one. Currently we have overcome this by assigning priority (weights) to the resources (Users, Platform and Roles), and the resource with the highest priority is assigned. Currently there is no merging of policy, but in our later version we will have it. The problem here is that a device can have multiple Roles. We were thinking of having the same priority based model (explained above) for Roles also. Is there something like this in IS roadmap in which case we can use the same for EMM? Regards, Nira -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 EMM 1.1.0 release!
to production. Our unique approach ensures that all support leverages our open development methodology and is provided by the very same engineers who build the technology. For additional support information please refer to http://wso2.com/support/ We welcome your feedback and would love to hear your thoughts on this release of WSO2 EMM. --WSO2 EMM Development Team-- -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] EMM devices - Different types for unique fields
Hi Dilshan Actually there is another type representing device identification. For iOS its universal device identifier (UDID) and for Android its the device id which is either IMEI (for GSM) or MEID (for CDMA phones). So it has to come as the 4th point. We do not need a 4th point for this. The second point I mentioned (in the previous mail) that is unique id generated by the device is the UDID for iOS and for Android it can be IMEI or MEID. In the server side, this is stored as *UDID* as it is uniquely for the device and the value is sent by the device. 1) Generated by EMM server. These are unique UUIDs you need to crate at EMM server end. This is simply a challenge which needs to identify the associated payloads in the enrollment flow. Right now we use user UID to deal with this. I think this has to be refactored and generate a UUID on request basis and store it in a temp table to be looked up with device type and user UID. The way proposed will be better since in the current implementation this has an issue if 2 devices enroll at the same time with the same username (but its very unlikely). Yes, currently the UserID is used as the challenge token to associated with the payload. This is the unique field that I mentioned that is generated by the EMM server. In the new version, we are generating a UUID and storing it in the device table as *challenge_token*. Currently we are using this only for iOS but we might need this when we add new devices like windows phone, etc... What I have proposed was that we generate a UUID for Android devices as well and Android devices use this to uniquely identify itself with the EMM server instead of using the GCM registration id. 3) Generated by the GCM / APNS This is actually specific to OS. For GCM you have the registration id. For iOS you have 3 tokens in MDM flow. Those are MDM token, magic token and unnlock token. Also for normal push you will be given a push token. Right now 3 MDM tokens are stored in the same field as a json string. Normal push token is saved in reg id field. This needs to be refactored. How do you deal with above 5 types of tokens in your new proposed way? For Android, it will have only the GCM registration id and for iOS this field will have the MDM token, magic token, unlock token and the normal push token. This is used by the server to sent message to the GCM / APNS. These are actually generated by a 3rd party for uniquely identifying the device. I am proposing that we store all these value in a json format in a new field called *token* in the devices table. The device should not use these values to communicate with the EMM server. Regards, Nira On Mon, May 5, 2014 at 12:46 PM, Dilshan Edirisuriya dils...@wso2.comwrote: Hi Niranjan, Actually there is another type representing device identification. For iOS its universal device identifier (UDID) and for Android its the device id which is either IMEI (for GSM) or MEID (for CDMA phones). So it has to come as the 4th point. Please find the comments on above points. 1) Generated by EMM server. These are unique UUIDs you need to crate at EMM server end. This is simply a challenge which needs to identify the associated payloads in the enrollment flow. Right now we use user UID to deal with this. I think this has to be refactored and generate a UUID on request basis and store it in a temp table to be looked up with device type and user UID. The way proposed will be better since in the current implementation this has an issue if 2 devices enroll at the same time with the same username (but its very unlikely). 3) Generated by the GCM / APNS This is actually specific to OS. For GCM you have the registration id. For iOS you have 3 tokens in MDM flow. Those are MDM token, magic token and unnlock token. Also for normal push you will be given a push token. Right now 3 MDM tokens are stored in the same field as a json string. Normal push token is saved in reg id field. This needs to be refactored. How do you deal with above 5 types of tokens in your new proposed way? Regards, Dilshan On Mon, May 5, 2014 at 10:29 AM, Niranjan Karunanandham niran...@wso2.com wrote: Hi all, When refracting the code that there are three types of unique fields [1https://github.com/wso2-dev/product-emm/commit/8396f05c8f82587f6e9eb1c6382138d6cf065381], namely 1. Generated by EMM server 2. Generated by the Device 3. Generated by the GCM / APNS The token generated by the GCM / APNS should not be used for communication between the device and the EMM server because it is generated by third party. We need to use either the generated by EMM server or by the device. Currently in android un-registration, we are using the GCM registration ID to communicate. This needs to be changed. [1] - https://github.com/wso2-dev/product-emm/commit/8396f05c8f82587f6e9eb1c6382138d6cf065381 Regards, Nira -- *Niranjan Karunanandham* Senior Software
[Architecture] EMM devices - Different types for unique fields
Hi all, When refracting the code that there are three types of unique fields [1https://github.com/wso2-dev/product-emm/commit/8396f05c8f82587f6e9eb1c6382138d6cf065381], namely 1. Generated by EMM server 2. Generated by the Device 3. Generated by the GCM / APNS The token generated by the GCM / APNS should not be used for communication between the device and the EMM server because it is generated by third party. We need to use either the generated by EMM server or by the device. Currently in android un-registration, we are using the GCM registration ID to communicate. This needs to be changed. [1] - https://github.com/wso2-dev/product-emm/commit/8396f05c8f82587f6e9eb1c6382138d6cf065381 Regards, Nira -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] EMM 1.1.0 release
Hi Dilshan, We are taking into consideration maintaining MDM and normal push certificates for each tenant. Had a offline discussion with Chathura Dilan and asked him to come up with a UI for it. This will be done by tenant admin and also the Super admin can configure this for the tenants. With regard to implementing it, i.e., use the specific certificate when notifying the device, the iOS jar needs to be changed. Can we have a meeting today after lunch regarding this?? Regards, Nira On Wed, Apr 30, 2014 at 11:46 AM, Dilshan Edirisuriya dils...@wso2.comwrote: Hi Chan, I think we have to focus more on multitenancy. Right now you have the point Fixes to the Policy Component (multiple policy, policy levels, tenancy). But other than this there are major areas which needs to be refactored. Eg: separate app deployment for tenant, maintaining mdm and normal push certificates for each tenant etc. Regards, Dilshan On Wed, Apr 30, 2014 at 9:47 AM, Chan duli...@wso2.com wrote: Hi folks, We have been discussing about the EMM 1.1.0 discussion earlier on and I sent a mail about it to @architecture before. But I thought of summarizing the long email thread :) The plan is to release EMM 1.1.0 with below improvements and features - Refactoring the EMM backend - Standardizing UI to use Caramel - Use the components library (ES team is using) - Separate emm_service app that will serve devices (this is for our ambitious goal of supporting 50, 000 devices) - Fixes to the Policy Component (multiple policy, policy levels, tenancy) - Removing MySQL dependency (running with H2) - Fixing the dependency to the email address - Use the refactored ES store and publisher - Test cases for EMM server-side - Test cases for Android and iOS client apps - Converting Jars developed for iOS into OSGi services - Fixing product related problems - Supporting Multiple User stores Since what is mentioned above is overwhelmingly big we have made the below plan - Planned release June 1st Going to hand over to QA - May 3rd week Development - April last week Task break down - - *Server* - HTTP API (emm emm_service apps) - All - Business Logic layer (Policy and Messaging - emm emm_service apps) - Niranjan and Harshan - Carbon refractor - Gayan - OAuth - Gayan - User Management - Dulitha and Kasun Dissanayake (iOS Kasun) - UI - Dilan - Enterprise Store Integration - Dilan and Dulitha - Unit Test - (Niranjan, Harshan, Kasun Dissanayake, Gayan) [all those involved in the Server] - Refractor and convert iOS jars to osgi service - Dilshan - *Android Client* - Performance optimization (checking *memory leaks and etc using DDMS*) - Insoh - Local notification integration testing - Inosh - Testing the new payload structure (implemented by Kasun) once the server side is done - Inosh - OAuth - Gayan - Unit Test - Krishanthi - *iOS Client* - OAuth - Gayan and Dilshan - Unit Test - Harshan Cheers~ -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email duli...@wso2.com duli...@wso2mobile.com* * ~Mobile +94712112165 %2B94712112165* * ~Website dulitha.me http://dulitha.me* * ~Twitter @dulitharw https://twitter.com/dulitharw* *~Github @dulichan https://github.com/dulichan* *~SO @chan http://stackoverflow.com/users/813471/chan* -- Dilshan Edirisuriya Senior Software Engineer - WSO2 Mob: + 94 777878905 http://wso2.com/ -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Git flow model
Hi all, The blog [1] explains how the Git work flow works. Below I have summarized what is mentioned in the blog. This work flow consists of two main branches (Master and Develop) and 3 supporting branches (Feature, Release and Hotfix branches). The supporting branches are used to allow parallel development between team members, ease of tracking features, prepare for production releases and to help in quickly fixing live production problems. Unlike the main branches which have an infinite lifetime, the supporting branches have a limited life time as they can be removed. - *Master *(naming convention: master) - This is the branch where the source code is in production-ready state. - *Develop *(naming convention: develop) - This is the branch in which the latest development changes for the next release are committed. When the branch reaches a stable point and is ready for release, it will be merged back into master and then tagged with a release number. - *Feature Branches* (naming convention: anything except master, develop, release-*, hotfix-*) - This is used to develop new features and eventually will be merged into develop or discarded. - Release branches (naming convention: release-*) - This is used to support preparation of a new production release like minor bug fixes and prepare meta-data for a release. This is branched off from the develop and must be merged back into develop and master. - Hotfix branches (naming convention: hotfix-*) - This is created when there is a critical bug that needs to be fixed in the released version (master). Once the bug is fixed, it needs to be merged to the master and develop branches. [1] - http://nvie.com/posts/a-successful-git-branching-model/ -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Git flow model
develop branch is not merged directly with master branch. It' merged through a release branch because of the above practical reason. @Chan: Yes, you are correct. The develop branch is not directly merged to the master, but release branches are supporting branches a limited life time and should eventually be removed. Therefore the release branch needs to be merged with the develop branch once it is ready to merge into master. Also Feature branches are not merged to the develop branch unless the feature is to be added to the upcoming release (as mentioned in the blog): *The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).* On Thu, Mar 27, 2014 at 10:31 PM, Chan duli...@wso2.com wrote: +1 to follow the above model. Small note on the Release branch - features are not assigned to versions until it's decided. Features are built in topic branches and gets merged to develop branch. Once we decide that 0.4 version is going to come with features that are available in develop -we branch off a release branch. The release branch is use to stabilize the code base and fix minor bugs. The release branch get's merged to the master and develop branch. A small correction on Niranjan's note- develop branch is not merged directly with master branch. It' merged through a release branch because of the above practical reason. Cheers~ On Thu, Mar 27, 2014 at 9:49 PM, Niranjan Karunanandham niran...@wso2.com wrote: Hi all, The blog [1] explains how the Git work flow works. Below I have summarized what is mentioned in the blog. This work flow consists of two main branches (Master and Develop) and 3 supporting branches (Feature, Release and Hotfix branches). The supporting branches are used to allow parallel development between team members, ease of tracking features, prepare for production releases and to help in quickly fixing live production problems. Unlike the main branches which have an infinite lifetime, the supporting branches have a limited life time as they can be removed. - *Master *(naming convention: master) - This is the branch where the source code is in production-ready state. - *Develop *(naming convention: develop) - This is the branch in which the latest development changes for the next release are committed. When the branch reaches a stable point and is ready for release, it will be merged back into master and then tagged with a release number. - *Feature Branches* (naming convention: anything except master, develop, release-*, hotfix-*) - This is used to develop new features and eventually will be merged into develop or discarded. - Release branches (naming convention: release-*) - This is used to support preparation of a new production release like minor bug fixes and prepare meta-data for a release. This is branched off from the develop and must be merged back into develop and master. - Hotfix branches (naming convention: hotfix-*) - This is created when there is a critical bug that needs to be fixed in the released version (master). Once the bug is fixed, it needs to be merged to the master and develop branches. [1] - http://nvie.com/posts/a-successful-git-branching-model/ -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email duli...@wso2.com duli...@wso2mobile.com* * ~Mobile +94712112165 %2B94712112165* * ~Website dulitha.me http://dulitha.me* * ~Twitter @dulitharw https://twitter.com/dulitharw* *~SO @chan http://stackoverflow.com/users/813471/chan* -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [ARCHITECTURE] APN connector for ESB
. *Problem* - *Whats the best way of persisting these info in ESB and is there any custom schema based forms to capture information like the app id and certificate info ?* Please see my above comments. In any means I don't think this needs to be saved in ESB. Just delegate that to the external party by allowing it to be routed through ESB. Also if a user has multiple devices there will be multiple tokens. Please see the above comment for not saving device tokens in ESB. I dont get Also if a user has multiple devices there will be multiple tokens. part. AFAIK APN clients are app id based rather than being user based. As a reply to Chan's commment on this : APN are app based. So only storing device tokens is not enough. Users should be able to create and entry, give it an id( may be the bundle id of the app), upload app specific APN certificates using a UI and then use the app id to send the self registration request using iOS. Does EMM support this ? Candidates for the client library are JavaPNS 2.2 [3] and java-apns [4]. Only use the notnoop java-apns. We have discussed this earlier. Other library you cannot ship according to its license. Later yes you can have push io or urban airship. But these things are introduce for the purpose of ease since with less configurations you can enable support for multiple platforms. If you implement connectors for major mobile platforms like iOS, Android, Windows, BB then I dont see a clear reason to support them since those are just push services which also uses the underline platform push technologies. If you implement so any user can make use of the services through the ESB connector. Noted the licensing part :-) We are yet to decide the app/device info storage part. Commenting on Chans comments. Also there is a known misconception about usage of Push Notifications. Push Notification itself will not have data (there is an exception for this) - push notification is a signal for the iOS device to contact a provider to get new data that's available (it's called Send-to-Sync by GCM). I think we need to re-think the whole picture when it comes to Push Notifications. == Chan you are talking about MDM push notifications here. MDM push notifications are something different than the normal push notifications. In MDM it just uses push technology to wake up the device allowing it to communicate with the registered MDM server. The purpose of the normal push is to send notifications directly to the device. So this involves a payload. You can set badges, sounds, priority etc. to this. Both statements are correct. APNs do support a small payload along with notification attributes such as badge, sound and alert. So its up to the user to use it as a data (very small data chunks) or as a trigger. === Shall we make the apns connectivity part in a way that is abstract to the connector? In the EMM product - we use apns (app push mdm push) - it would better if we can leverage a single component through out the platform. = Yes we have implemented this in EMM. That supports both normal push notifications and mdm push notifications. Yes I will make this an orbit bundle so you can use this directly. +1 for this. I'll have a look at EMM to get an idea. Regards, Dilshan https://github.com/notnoop/java-apns Dilshan Edirisuriya Senior Software Engineer - WSO2 Mob: + 94 777878905 http://wso2.com/ -- Rushmin Fernando Technical Lead Mobile : +94772310855 -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email duli...@wso2.com duli...@wso2mobile.com* * ~Mobile +94712112165 %2B94712112165* * ~Website dulitha.me http://dulitha.me* * ~Twitter @dulitharw https://twitter.com/dulitharw* *~SO @chan http://stackoverflow.com/users/813471/chan* -- Dilshan Edirisuriya Senior Software Engineer - WSO2 Mob: + 94 777878905 http://wso2.com/ -- Rushmin Fernando Technical Lead Mobile : +94772310855 -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email duli...@wso2.com duli...@wso2mobile.com* * ~Mobile +94712112165 %2B94712112165* * ~Website dulitha.me http://dulitha.me* * ~Twitter @dulitharw https://twitter.com/dulitharw* *~SO @chan http://stackoverflow.com/users/813471/chan* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// ___ Architecture mailing list Architecture@wso2.org https://mail.wso2
Re: [Architecture] SSO IDP Proxy Application + SDK
Hi Gayan, Here the IDP proxy app is only used to get the authorization code from the WSO2 IS and pass it to the SDK. After which the SDK is communicates directly with the WSO2 IS to get the access token and manage the access token and refresh token. Just a small clarification why we can't use the IDP proxy app to do this, .i.e, let the IDP proxy app manage the access token and refresh token for each app. Therefore cutting off the connection between the SDK and the WSO2 IS. Here if the access token expires then the SDK will call the IDP proxy app to get the token refreshed. On Mon, Mar 10, 2014 at 3:58 PM, Gayan Gunawardana ga...@wso2.com wrote: Image attached On Mon, Mar 10, 2014 at 3:51 PM, Gayan Gunawardana ga...@wso2.com wrote: Hi All, Problem: Implement SSO for enterprise mobile apps The idea is to provide SDK for mobile apps developers within the organization, then they can integrate SDK inside the application and implement SSO across required applications. Provide (SDK + Mobile IDP proxy app) To achieve above purpose we plan to utilize oauth 2.0 with *Authorization code* grant type. Briefly Explaining message flow : Initially new application has to be registered in WSO2 IS under Oauth management and obtain client_key, client_secret, Access Token Url and Authorize Url 1. SDK initiate the process by sending client_key, redirect_url and scope to mobile IDP proxy app 2. IDP proxy app obtain Authorization code 3. SDK (in side mobile app) receive Authorization code 4. SDK send second request directly to WSO2 IS with Authorization code, client secret and redirect_url 5. SDK obtain access token 6. Mobile app pass access token to resource server 7. Resource server contact IPD and validate access token This is much similar to Facebook approach where facebook application act as mobile IDP proxy app and they provide SDK to develop apps. All your suggestions are welcome. -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: ga...@wso2.com Mobile: +94 (71) 8020933 Blog: http://gayanj2ee.blogspot.com/ -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: ga...@wso2.com Mobile: +94 (71) 8020933 Blog: http://gayanj2ee.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] EMM Deployment pattern
Hi all, On 13th February, the mobile team had a discussion with Kishanthan, Amila, Chamara and Nirmal regarding our deployment process (Previous mail thread subject: Issue with tenancy specific files in app layer). Basics In EMM, there are 4 jaggeryapps namely - mdm - mam - publisher - store Mostly used 2 apps are MDM and Store. How EMM contacts devices? The EMM connects to the enrolled devices in an asynchronous process. How this works is that the EMM server will contact the APNshttps://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html(Apple Push Notification server) or GCM http://developer.android.com/google/gcm/index.html (Google Cloud Messaging) which will inform the device to contact the EMM server. The reason as to why this is asynchronous is that when the EMM server contacts the APNs / GCM, the device might be switched off, it can be outside the network, the internet connection can be switched off, the device might be in idle state and etc... Device Monitoring process In EMM, the enrolled devices are constantly monitored based on a specific time interval. This is an important process since all the operation like policy compliance, apps installation, etc., depends on this. The EMM server dispatches messages to the enrolled device using the above explain mechanism. Tenancy The 4 apps distributed are placed in the repository/deployments/server/jaggeryapps which is the super tenant space. The multi-tenancy aspect of these apps are handled in the app layer (following the SaaS model). MDM app have below tenant specific files - config.json -- this has tenancy specific configuration like the domain name that should appear in the ios profile - ui.json -- tenant specific theme - license.txt -- This is the policy agreement that would appear when the user tries to enroll his / her device (Android / iOS) When we are adding a new tenant - currently these files have to be manually created in the filesystem (Refer Multi Tenancy in EMM Documentationhttp://docs.wso2.org/display/EMM100/Multitenancy ). Deployment layout First scenario is a user performing an operation from the web console. It will send a request via the ELB to the EMM and EMM will dispatch a message to GCM or APNS. Device will contact EMM via the ELB when it receives a notification from GCM or APNS. Second scenario is - the EMM server running a process and dispatching monitoring messages to GCM or APNS. Once the device get a monitoring notification it will contact EMM via the ELB. How the monitoring process starts will be explained below. Correlations Currently our monitoring thread implementation is based on JavaScript setInterval. Using correlation - a node will be selected as a policy monitoring member which will be the outgoing server. There are discussions on changing this to a Task Server based implementation. SVN DepSync and Publisher Basically dep sync will sync all the nodes to have the same app. The tenant related config files added in mdm will be propagated to all the nodes. Also our current publisher implementation relies on persisting uploaded files to the file system. Once a file is uploaded via the publisher - it will be added to the current node's file system. Afterwards DepSync will sync these files across all nodes. We are currently discussing on how to isolate these to a single storage app which is discussed in the architecture list [mail thread subject: Unified Storage Proposal]. -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2 Inc.: http://www.wso2.com M: +94 777 749 661 http:/// ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Creating a separate application for User Management
+1 On Fri, Nov 1, 2013 at 5:58 PM, Chan duli...@wso2.com wrote: Hi Shan/Guys, How about having a separate applications to handle users and roles for the EMM. We are currently having this facility in MDM console and we need to have the facility again in the MAM console (What about MBaSS when it rolls out?). Our app bundles will look as below if we add a Admin UI for App Admins (MDM admin and MAM admin). WDYT? [1] - Enterprise Mobile Management platform *Peace~* --- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email duli...@wso2mobile.com duli...@wso2mobile.com* * ~Mobile +94712112165 %2B94712112165* * ~Website dulithawijewantha.com http://dulithawijewantha.com/* * ~Blog blog.dulithawijewantha.com http://dulichan.github.io/chan/* * ~Twitter @dulitharw https://twitter.com/dulitharw* -- *Niranjan Karunanandham* Senior Software Engineer - WSO2 Inc. WSO2Mobile Inc.: http://wso2mobile.com M: +94 777 749 661 http:/// 6B0F5F81-A8A3-40B7-ADB4-486CED138701.png___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
