Re: [Architecture] [Appfactory] Tenant Isolation in Jenkins
HI sahmika,
I discussed about this with sameera jayasoma furthermore . As he said you
better to maintain two runtime (shared and exclusive). Better if you can
have a discussion about this with him.
*Harsha Thirimanna*
Senior Software Engineer; WSO2, Inc.; http://wso2.com
* http://www.apache.org/**
email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770**
twitter: **http://twitter.com/ http://twitter.com/afkham_azeez**
harshathirimann
linked-in: **http: http://lk.linkedin.com/in/afkhamazeez**//
www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*
*
*
*Lean . Enterprise . Middleware*
*
*
On Tue, Jul 30, 2013 at 12:50 AM, Shamika Ariyawansa sham...@wso2.comwrote:
HI Harsha,
Ya this worked and also have to put EnvironmentsJENKINS,
Carbon/Environments
to make sure carbon libraries are loaded to the class path.
Thanks
On Mon, Jul 29, 2013 at 9:20 PM, Harsha Thirimanna hars...@wso2.comwrote:
Hi Shamika,
As I told you, you can create a runtime for the JENKINS
in ${carbon.home}/lib/runtimes/jenkins and put that libraries in to that.
Put a new entry to
${carbon.home}/repository/conf/tomcat/webapp-classloading-environments.xml
ExclusiveEnvironment
NameJENKINS/Name
Classpath${carbon.home}/lib/runtimes/cxf/*.jar;${carbon.home}/lib/runtimes/jenkins//Classpath
/ExclusiveEnvironment
then you have to put a new webapp-classloading.xml in to jenkins.war
with this change to that
EnvironmentsJENKINS/Environments
This runtime will be loaded as per webapp.
If you want to have a shared runtime to all the jenkins wars in a
appserver , then you can have another runtime and put it
as SharedEnvironment and use it in Environments.
--
Shamika Ariyawansa
Senior Software Engineer
Mob:+ 94 772929486
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Encrypting Access/Refresh Tokens in OAuth Component
Hi Prabath,
In addition to these tokens, AM has application tokens which are handled in
a separate path. Unlike access tokens, they need to decryptable to original
format since they need to be shown in a UI to the user.
What would be the best way to handle application tokens in this case? Is it
okay to use one way hashing for access/refresh tokens and a two way
encryption algorithm here for application tokens?
Thanks
Rajeev
On Fri, Jul 26, 2013 at 7:07 PM, Prabath Siriwardena prab...@wso2.comwrote:
AFAIK tokens are stored only in one place..
Thanks regards,
-Prabath
On Fri, Jul 26, 2013 at 7:01 PM, Rajeev Sampath raje...@wso2.com wrote:
Hi Ratha,
On Fri, Jul 26, 2013 at 6:32 PM, Vijayaratha Vijayasingam
rat...@wso2.com wrote:
On 26 July 2013 17:50, Rajeev Sampath raje...@wso2.com wrote:
Hi Prabath,
On Fri, Jul 26, 2013 at 3:35 PM, Prabath Siriwardena
prab...@wso2.comwrote:
On Fri, Jul 26, 2013 at 3:24 PM, Prabath Siriwardena prab...@wso2.com
wrote:
There three aspects..
1. Protect the confidentiality of the token at rest (in storage)
2. Protect the confidentiality of the token in transit.
3. Protect the confidentiality of the token from the client.
[2] is achieved through TLS.
[3] this is the one which mentioned in the spec. This is needed if we
have to include certain information in to the token that should not be
visible to the client.
Doing [3] is very costly. What client gets there is an encrypted
token. So - its the same encrypted token that it will send to access
resources. So - for each request we need to decrypt it.
Also the issue in [3] is - if you store the encrypted token in the
database - somebody having access to the database - can take the
encrypted
token and use it to access the API (he does not need to decrypt it).
What I would suggest is this.
In the access token we issues we have some information parts and a
secret part.
Information part is something like domain name.. like wise. Secret
part is the randomly generated string.
Access Token = INFORMATION_PART + SECRET_KEY
This is what I suggest..
Access Token = Base64Encode(INFORMATION_PART + : + SECRET_KEY)
Client will get the Access Token and we store *Hash(SECRET_KEY)* in
the database (no encryption)
Correction -- we store *Hash(Access Token)*
Now - when accessing the API client will send the Access Token
Decoded Access Token = Base64Decode(Access Token)
= INFORMATION_PART + : +
SECRET_KEY
Now to validate the token we check, *Hash(SECRET_KEY{from request})
= **Hashed Secret Key from database*
Correction -- *Hash(Access Token{from request}) = **Hashed Access
Token from database*
*
*
In addition to these at IS level, access tokens are stored in AM as
well. So IMO for those, we'll have to use a symmetric algorithm that can
also decrypt and get the original key from an encrypted key.
Why do we need decryption if we use hashing? And where will we need the
original key, if we issue the encoded token to client?
My concern was on a scenario where AM having to use a stored token in non
hashed form (such as sending it to OAuth). In that case, OAuth will be
expecting an encoded but not hashed key (which I referred to as original
key here). So if the keys can't be converted back to the original state at
AM level won't that be a problem?
Or else won't there be such scenarios?
Thanks
Rajeev
Thanks
Rajeev
**
Thanks regards,
-Prabath
*
*
This way we do not want to worry about encryption - and we also do
not store access token in clear text in the database.
Refresh token can be just stored as a hash.
Thanks regards,
-Prabath
On Fri, Jul 26, 2013 at 2:59 PM, Sumedha Rubasinghe sume...@wso2.com
wrote:
We need to attend to $subject.
OAuth2 spec also recommends this in it's Threat Mitigation section.
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.2
For those cases where the client is prevented from observing the
contents of the token, token encryption MUST be applied in addition to
the
usage of TLS protection.
Some design considerations.
1. Should be configurable (default off), configured via identity.xml
2. Need to consider token validation flow as well (hash should be
generated of incoming token compared)
3. Should we also store encrypting algorithm as well? (for backward
compatibility if it changes after sometime) - Is this a real scenario?
--
/sumedha
b : bit.ly/sumedha
--
Thanks Regards,
Prabath
Mobile : +94 71 809 6732
http://blog.facilelogin.com
http://RampartFAQ.com
--
Thanks Regards,
Prabath
Mobile : +94 71 809 6732
http://blog.facilelogin.com
http://RampartFAQ.com
--
Rajeev Sampath
Senior Software Engineer
WSO2, Inc.; http://www.wso2.com.
Mobile:* +94716265766
*
___
Architecture mailing list
Architecture@wso2.org
[Architecture] Authenticating the Task parent in HumanTask coordination service.
As we discussed in HumanTask protocol Implementation, we decided to implement Humantask engine's protocol handler as an admin service. This admin service provides an operation to exit a task. The reason behind implementing this service as an admin service is Exiting a Task should only be invoked by the Task Parent, the BPEL engine who created the task. So in the first cut implementation, we are thinking to authenticate task parent as follows. When server setup, it creates a default user (which is configurable) who has only permission to exit a task. When the BPEL engine calls the exit operation, use basic auth to call the admin service. Later we are thinking to add support for session/token based authentication mechanism for this module. Thanks, Hasitha. -- Hasitha Aravinda, Software Engineer, WSO2 Inc. Email: hasi...@wso2.com Mobile: +94 71 8 210 200 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Support for publishing into multiple API Stores in API Manager
This discussion happened as part of *Enterprise Store* discussion. Participants: Nuwan, Azeez, Sanjiva, Srinath, NuwanD, Lalaji, Sanjeewa, Sumedha *Current Functionality:* 1. At the point of publishing an API, publisher can select the visibility scope (one of Globally visible, selected tenants, tenant only [private/public]). 2. Based on selected scope, APIs will be created with correct set of permission indicators in WSO2 Governance Registry 3. @ the point of populating a store, based on the store type APIs will be fetched from tenant registries *Limitations in this approach:* 1. Assumption of single registry for all tenants (fetching, publishing criteria fails with tenant partitioning) 2. High computational cost for populating global tenant store (also known as super tenant store) 3. API publishing is only supported for WSO2 API Store type 4. Tight coupling with WSO2 API Store semantics for API publishing fetching *New Approach:* 1. At the point of publishing an API, it can also be published to multiple (external) stores 2. These stores will be defined through configuration (run time registration can be considered for future work, limited by lack of standard API for publishing API) 3. APIs will published to external stores through their APIs. This has several design considerations: - Any API store can be integrated to WSO2 API Publisher through this approach - WSO2 API Store will also be treated as an external one - Concept of Super Tenant Store will no longer be applicable *** - If an API is shared with another tenant store, it will be stored in that tenant's storage (if sharing is removed, relevant removal should follow) 4. *** When navigated to http://IP/Domain/store (formally known as Super tenant's store), it will show a list of tenant store URLs only 5. This concept should be supported in WSO2 Generic Store as well Feedback welcome. -- /sumedha b : bit.ly/sumedha ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Support for publishing into multiple API Stores in API Manager
Hi Sumedha, On Tue, Jul 30, 2013 at 12:45 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This discussion happened as part of *Enterprise Store* discussion. Participants: Nuwan, Azeez, Sanjiva, Srinath, NuwanD, Lalaji, Sanjeewa, Sumedha *Current Functionality:* 1. At the point of publishing an API, publisher can select the visibility scope (one of Globally visible, selected tenants, tenant only [private/public]). 2. Based on selected scope, APIs will be created with correct set of permission indicators in WSO2 Governance Registry 3. @ the point of populating a store, based on the store type APIs will be fetched from tenant registries *Limitations in this approach:* 1. Assumption of single registry for all tenants (fetching, publishing criteria fails with tenant partitioning) 2. High computational cost for populating global tenant store (also known as super tenant store) 3. API publishing is only supported for WSO2 API Store type 4. Tight coupling with WSO2 API Store semantics for API publishing fetching *New Approach:* 1. At the point of publishing an API, it can also be published to multiple (external) stores 2. These stores will be defined through configuration (run time registration can be considered for future work, limited by lack of standard API for publishing API) 3. APIs will published to external stores through their APIs. This has several design considerations: - Any API store can be integrated to WSO2 API Publisher through this approach - WSO2 API Store will also be treated as an external one - Concept of Super Tenant Store will no longer be applicable *** - If an API is shared with another tenant store, it will be stored in that tenant's storage (if sharing is removed, relevant removal should follow) 4. *** When navigated to http://IP/Domain/store (formally known as Super tenant's store), it will show a list of tenant store URLs only 5. This concept should be supported in WSO2 Generic Store as well We have already started implementation of the generic publisher in the above fashion. Regards, /Nuwan Feedback welcome. -- /sumedha b : bit.ly/sumedha -- *Thanks Regards, Nuwan Bandara Technical Lead; **WSO2 Inc. * *lean . enterprise . middleware | http://wso2.com * *blog : http://nuwanbando.com; email: nu...@wso2.com; phone: +94 11 763 9629 * http://www.nuwanbando.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Support for publishing into multiple API Stores in API Manager
Hi, I have few questions related to this..Please find them inline below.. On Tue, Jul 30, 2013 at 12:15 AM, Sumedha Rubasinghe sume...@wso2.comwrote: This discussion happened as part of *Enterprise Store* discussion. Participants: Nuwan, Azeez, Sanjiva, Srinath, NuwanD, Lalaji, Sanjeewa, Sumedha *Current Functionality:* 1. At the point of publishing an API, publisher can select the visibility scope (one of Globally visible, selected tenants, tenant only [private/public]). 2. Based on selected scope, APIs will be created with correct set of permission indicators in WSO2 Governance Registry 3. @ the point of populating a store, based on the store type APIs will be fetched from tenant registries *Limitations in this approach:* 1. Assumption of single registry for all tenants (fetching, publishing criteria fails with tenant partitioning) 2. High computational cost for populating global tenant store (also known as super tenant store) 3. API publishing is only supported for WSO2 API Store type 4. Tight coupling with WSO2 API Store semantics for API publishing fetching *New Approach:* 1. At the point of publishing an API, it can also be published to multiple (external) stores I would like to know how the visibility scope applies with this approach. Does the existing visibility scopes will be available with new approach too..If so how the mappings would be like? For example how the 'Public' visibility scope define.. 2. These stores will be defined through configuration (run time registration can be considered for future work, limited by lack of standard API for publishing API) 3. APIs will published to external stores through their APIs. This has several design considerations: - Any API store can be integrated to WSO2 API Publisher through this approach - WSO2 API Store will also be treated as an external one - Concept of Super Tenant Store will no longer be applicable *** - If an API is shared with another tenant store, it will be stored in that tenant's storage (if sharing is removed, relevant removal should follow) 4. *** When navigated to http://IP/Domain/store (formally known as Super tenant's store), it will show a list of tenant store URLs only With current Store implementation,are we going to show tenant store URLs for anonymous view as well..? And even a user logged to /Store and if he has a tenant store URL with him,if he is not from that specific tenant,he cannot login to tenant Store and continue further processing.So if we show as above,the only use-case is users can browse the APIs from tenant stores.. And additionally,with this approach the 'Public' visibility scope of tenants' APIs not getting useful,as there's no view of 'Public' Store for tenants with this approach and only 'Tenant Store' view will available.. 5. This concept should be supported in WSO2 Generic Store as well Feedback welcome. Thanks; -- /sumedha b : bit.ly/sumedha -- Lalaji Sureshika WSO2, Inc.; http://wso2.com/ email: lal...@wso2.com; cell: +94 71 608 6811 blog: http://lalajisureshika.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Support for publishing into multiple API Stores in API Manager
On Tue, Jul 30, 2013 at 12:45 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This discussion happened as part of *Enterprise Store* discussion. Participants: Nuwan, Azeez, Sanjiva, Srinath, NuwanD, Lalaji, Sanjeewa, Sumedha *Current Functionality:* 1. At the point of publishing an API, publisher can select the visibility scope (one of Globally visible, selected tenants, tenant only [private/public]). 2. Based on selected scope, APIs will be created with correct set of permission indicators in WSO2 Governance Registry 3. @ the point of populating a store, based on the store type APIs will be fetched from tenant registries *Limitations in this approach:* 1. Assumption of single registry for all tenants (fetching, publishing criteria fails with tenant partitioning) 2. High computational cost for populating global tenant store (also known as super tenant store) 3. API publishing is only supported for WSO2 API Store type 4. Tight coupling with WSO2 API Store semantics for API publishing fetching *New Approach:* 1. At the point of publishing an API, it can also be published to multiple (external) stores 2. These stores will be defined through configuration (run time registration can be considered for future work, limited by lack of standard API for publishing API) 3. APIs will published to external stores through their APIs. This has several design considerations: - Any API store can be integrated to WSO2 API Publisher through this approach - WSO2 API Store will also be treated as an external one - Concept of Super Tenant Store will no longer be applicable *** - If an API is shared with another tenant store, it will be stored in that tenant's storage (if sharing is removed, relevant removal should follow) 4. *** When navigated to http://IP/Domain/store (formally known as Super tenant's store), it will show a list of tenant store URLs only Right now we do not allow a tenant user (when logged in) to view other tenant stores. You can view other tenant stores if you are a super tenant user or when you are in anonymous mode (not logged in). If this behavior is to remain as it is, what is the purpose of displaying other tenant's store URLs on the /store? 5. This concept should be supported in WSO2 Generic Store as well Feedback welcome. Thanks, NuwanD. -- /sumedha b : bit.ly/sumedha ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nuwan Dias Senior Software Engineer - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Support for publishing into multiple API Stores in API Manager
Hi With the new proposal the previous super tenant store will be a store of stores. If we take an example lets assume there are two tenants WSO2 and Foo, the super tenant store will just show URLs of WSO2 store and Foo Store, where users can navigate to. When an anonymous user goes to one of these store, (s)he will only see the public APIs of that tenant. Subsequently the older super store will be replaced by a simple OOTB store, where any tenant can push APIs. its like a public store hosted somewhere, which anybody can push APIs. Regards, /Nuwan On Tue, Jul 30, 2013 at 1:08 PM, Nuwan Dias nuw...@wso2.com wrote: On Tue, Jul 30, 2013 at 12:45 PM, Sumedha Rubasinghe sume...@wso2.comwrote: This discussion happened as part of *Enterprise Store* discussion. Participants: Nuwan, Azeez, Sanjiva, Srinath, NuwanD, Lalaji, Sanjeewa, Sumedha *Current Functionality:* 1. At the point of publishing an API, publisher can select the visibility scope (one of Globally visible, selected tenants, tenant only [private/public]). 2. Based on selected scope, APIs will be created with correct set of permission indicators in WSO2 Governance Registry 3. @ the point of populating a store, based on the store type APIs will be fetched from tenant registries *Limitations in this approach:* 1. Assumption of single registry for all tenants (fetching, publishing criteria fails with tenant partitioning) 2. High computational cost for populating global tenant store (also known as super tenant store) 3. API publishing is only supported for WSO2 API Store type 4. Tight coupling with WSO2 API Store semantics for API publishing fetching *New Approach:* 1. At the point of publishing an API, it can also be published to multiple (external) stores 2. These stores will be defined through configuration (run time registration can be considered for future work, limited by lack of standard API for publishing API) 3. APIs will published to external stores through their APIs. This has several design considerations: - Any API store can be integrated to WSO2 API Publisher through this approach - WSO2 API Store will also be treated as an external one - Concept of Super Tenant Store will no longer be applicable *** - If an API is shared with another tenant store, it will be stored in that tenant's storage (if sharing is removed, relevant removal should follow) 4. *** When navigated to http://IP/Domain/store (formally known as Super tenant's store), it will show a list of tenant store URLs only Right now we do not allow a tenant user (when logged in) to view other tenant stores. You can view other tenant stores if you are a super tenant user or when you are in anonymous mode (not logged in). If this behavior is to remain as it is, what is the purpose of displaying other tenant's store URLs on the /store? 5. This concept should be supported in WSO2 Generic Store as well Feedback welcome. Thanks, NuwanD. -- /sumedha b : bit.ly/sumedha ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nuwan Dias Senior Software Engineer - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 -- *Thanks Regards, Nuwan Bandara Technical Lead; **WSO2 Inc. * *lean . enterprise . middleware | http://wso2.com * *blog : http://nuwanbando.com; email: nu...@wso2.com; phone: +94 11 763 9629 * http://www.nuwanbando.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Webapp Metadata Persistence
Why are we not storing this metadata in the registry? May be I am missing something .. but to me that is right place to put them. On Wed, Jul 31, 2013 at 10:09 AM, Sagara Gunathunga sag...@wso2.com wrote: On Wed, Jul 31, 2013 at 10:01 AM, Supun Malinga sup...@wso2.com wrote: +1 for this This can solve many current limitations we have on webapps in a cluster.. In addition to that all of our web app (including JAX-WS/JAX-RS) based new features will be based on this component. Thanks ! For eg. Preserving webapp state. Thanks. -- Supun Malinga Sent from my phone. On 29 Jul 2013 11:51, Kasun Gajasinghe kas...@wso2.com wrote: Hi Srinath, Each webapp will contain its own metafile. It can have a metadata like - *enable.statistics*=true Thanks, KasunG On Mon, Jul 29, 2013 at 11:39 AM, Srinath Perera srin...@wso2.comwrote: What is an example of Webapp metadata? --Srinath On Sat, Jul 27, 2013 at 7:35 PM, Sagara Gunathunga sag...@wso2.comwrote: On Sat, Jul 27, 2013 at 9:51 AM, Kasun Gajasinghe kas...@wso2.comwrote: Hi, We have added support for webapp metadata persistence. This is used to synchronize the metadata changes in a cluster, and to reload the metadata during server restarts. Currently, we use this to persist the per webapp BAM webapp statistics publishing enable/disable switch. We can extend this later on to persist other metadata we would need as well. We have also written a webapp metadata deployer to read the update deployed webapps using the metadata. The webapp metadata is persisted in to CARBON-HOME/repository/deployment/server/*artifactMetafiles/webapp* . This is implemented using the unified metadata api that has been added to the kernel. Any artifact management can leverage the unified metadata api to persist the artifact metadata. The metadata persistence is done using simple properties file which eliminates the need of complex things like xpath etc. +1 Thanks ! Thanks, KasunG -- *Kasun Gajasinghe* Software Engineer; Development Technologies Team, WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe * * *blog: **http://kasunbg.org* http://kasunbg.org * twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg * * ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kasun Gajasinghe* Software Engineer; Development Technologies Team, WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe * * *blog: **http://kasunbg.org* http://kasunbg.org * twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg * * ___ 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 -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Srinath Perera, Ph.D. Director, Research, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Webapp Metadata Persistence
AFAIK If we store them in registry, any changes to meta data, will not be distributed among other cluster members. AFAIK registry is synced when server starts. Thanks Geeth *G. K. S. Munasinghe * *Software Engineer,* *WSO2, Inc. http://wso2.com * *lean.enterprise.middleware.* * * email: ge...@wso2.com phone:(+94) 777911226 On Wed, Jul 31, 2013 at 10:33 AM, Geeth Munasinghe ge...@wso2.com wrote: On Sat, Jul 27, 2013 at 7:21 PM, Kasun Gajasinghe kas...@wso2.com wrote: Hi, We have added support for webapp metadata persistence. This is used to synchronize the metadata changes in a cluster, and to reload the metadata during server restarts. Currently, we use this to persist the per webapp BAM webapp statistics publishing enable/disable switch. We can extend this later on to persist other metadata we would need as well. We have also written a webapp metadata deployer to read the update deployed webapps using the metadata. The webapp metadata is persisted in to CARBON-HOME/repository/deployment/server/*artifactMetafiles/webapp*. This is implemented using the unified metadata api that has been added to the kernel. Any artifact management can leverage the unified metadata api to persist the artifact metadata. The metadata persistence is done using simple properties file which eliminates the need of complex things like xpath etc. Thanks, KasunG +1 Thanks. -- *Kasun Gajasinghe* Software Engineer; Development Technologies Team, WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe * * *blog: **http://kasunbg.org* http://kasunbg.org * twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg * * ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Webapp Metadata Persistence
On Wed, Jul 31, 2013 at 10:30 AM, Srinath Perera srin...@wso2.com wrote: Why are we not storing this metadata in the registry? May be I am missing something .. but to me that is right place to put them. (1) This is to make it compatible with the way we handle metadata for Axis2 services on AS, for Axis2 service matadata such as security, policy, RM, throttling, service enabling/disabling , SOAP tracing are persists in a XML file within the repository/deployment/server/servicemetafiles directory. I'm not aware with exact design decision behind this but we haven't face any issue with this architecture it worked as expected in both standalone and clustered setups so I don't think we need something new or something incompatible with service metadata to handle metadeta belong to web applications. (2) When adding QoS to a Axis2 service those changes will propagate to other clustered nodes in the real time I'm not sure whether we can achieve same thing using registry easily. Also DepSync support and MetadataDeployer wrote for service metadata management will be reuse for web app metadata too this is kind of adding missing peace. In maintenance wise we don't need to maintain two different architectures to handle meta data belong to web-apps and services. Thanks ! On Wed, Jul 31, 2013 at 10:09 AM, Sagara Gunathunga sag...@wso2.comwrote: On Wed, Jul 31, 2013 at 10:01 AM, Supun Malinga sup...@wso2.com wrote: +1 for this This can solve many current limitations we have on webapps in a cluster.. In addition to that all of our web app (including JAX-WS/JAX-RS) based new features will be based on this component. Thanks ! For eg. Preserving webapp state. Thanks. -- Supun Malinga Sent from my phone. On 29 Jul 2013 11:51, Kasun Gajasinghe kas...@wso2.com wrote: Hi Srinath, Each webapp will contain its own metafile. It can have a metadata like - *enable.statistics*=true Thanks, KasunG On Mon, Jul 29, 2013 at 11:39 AM, Srinath Perera srin...@wso2.comwrote: What is an example of Webapp metadata? --Srinath On Sat, Jul 27, 2013 at 7:35 PM, Sagara Gunathunga sag...@wso2.comwrote: On Sat, Jul 27, 2013 at 9:51 AM, Kasun Gajasinghe kas...@wso2.comwrote: Hi, We have added support for webapp metadata persistence. This is used to synchronize the metadata changes in a cluster, and to reload the metadata during server restarts. Currently, we use this to persist the per webapp BAM webapp statistics publishing enable/disable switch. We can extend this later on to persist other metadata we would need as well. We have also written a webapp metadata deployer to read the update deployed webapps using the metadata. The webapp metadata is persisted in to CARBON-HOME/repository/deployment/server/*artifactMetafiles/webapp *. This is implemented using the unified metadata api that has been added to the kernel. Any artifact management can leverage the unified metadata api to persist the artifact metadata. The metadata persistence is done using simple properties file which eliminates the need of complex things like xpath etc. +1 Thanks ! Thanks, KasunG -- *Kasun Gajasinghe* Software Engineer; Development Technologies Team, WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe * * *blog: **http://kasunbg.org* http://kasunbg.org * twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg * * ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kasun Gajasinghe* Software Engineer; Development Technologies Team, WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe * * *blog: **http://kasunbg.org* http://kasunbg.org * twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg * * ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list
Re: [Architecture] Webapp Metadata Persistence
Hi Sagara, Ok, Lets keep it as it is for now. --Srinath On Wed, Jul 31, 2013 at 10:52 AM, Sagara Gunathunga sag...@wso2.com wrote: On Wed, Jul 31, 2013 at 10:30 AM, Srinath Perera srin...@wso2.com wrote: Why are we not storing this metadata in the registry? May be I am missing something .. but to me that is right place to put them. (1) This is to make it compatible with the way we handle metadata for Axis2 services on AS, for Axis2 service matadata such as security, policy, RM, throttling, service enabling/disabling , SOAP tracing are persists in a XML file within the repository/deployment/server/servicemetafiles directory. I'm not aware with exact design decision behind this but we haven't face any issue with this architecture it worked as expected in both standalone and clustered setups so I don't think we need something new or something incompatible with service metadata to handle metadeta belong to web applications. (2) When adding QoS to a Axis2 service those changes will propagate to other clustered nodes in the real time I'm not sure whether we can achieve same thing using registry easily. Also DepSync support and MetadataDeployer wrote for service metadata management will be reuse for web app metadata too this is kind of adding missing peace. In maintenance wise we don't need to maintain two different architectures to handle meta data belong to web-apps and services. Thanks ! On Wed, Jul 31, 2013 at 10:09 AM, Sagara Gunathunga sag...@wso2.comwrote: On Wed, Jul 31, 2013 at 10:01 AM, Supun Malinga sup...@wso2.com wrote: +1 for this This can solve many current limitations we have on webapps in a cluster.. In addition to that all of our web app (including JAX-WS/JAX-RS) based new features will be based on this component. Thanks ! For eg. Preserving webapp state. Thanks. -- Supun Malinga Sent from my phone. On 29 Jul 2013 11:51, Kasun Gajasinghe kas...@wso2.com wrote: Hi Srinath, Each webapp will contain its own metafile. It can have a metadata like - *enable.statistics*=true Thanks, KasunG On Mon, Jul 29, 2013 at 11:39 AM, Srinath Perera srin...@wso2.comwrote: What is an example of Webapp metadata? --Srinath On Sat, Jul 27, 2013 at 7:35 PM, Sagara Gunathunga sag...@wso2.comwrote: On Sat, Jul 27, 2013 at 9:51 AM, Kasun Gajasinghe kas...@wso2.comwrote: Hi, We have added support for webapp metadata persistence. This is used to synchronize the metadata changes in a cluster, and to reload the metadata during server restarts. Currently, we use this to persist the per webapp BAM webapp statistics publishing enable/disable switch. We can extend this later on to persist other metadata we would need as well. We have also written a webapp metadata deployer to read the update deployed webapps using the metadata. The webapp metadata is persisted in to CARBON-HOME/repository/deployment/server/* artifactMetafiles/webapp*. This is implemented using the unified metadata api that has been added to the kernel. Any artifact management can leverage the unified metadata api to persist the artifact metadata. The metadata persistence is done using simple properties file which eliminates the need of complex things like xpath etc. +1 Thanks ! Thanks, KasunG -- *Kasun Gajasinghe* Software Engineer; Development Technologies Team, WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe * * *blog: **http://kasunbg.org* http://kasunbg.org * twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg * * ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kasun Gajasinghe* Software Engineer; Development Technologies Team, WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe * * *blog: **http://kasunbg.org* http://kasunbg.org * twitter: **http://twitter.com/kasunbg* http://twitter.com/kasunbg * * ___ Architecture mailing list
