Re: [Architecture] Jaggery - Ability to intercept request/response
Hi all, This was accomplished successfully by, Sandboxing render method of jagg.jag + routing all ajax calls to block layer via router.jag by means of a url mapping. Lot of thanks to SameeraM Ruchira. On Wed, Mar 18, 2015 at 2:13 AM, Ruchira Wageesha ruch...@wso2.com wrote: On Tue, Mar 17, 2015 at 6:23 PM, Mahesh Chinthaka mahe...@wso2.com wrote: Hi all, This is what I have tried up to now, I tried with Method 1 explained by Ruchira, which is to add a router.jag and intercept incoming requests and route them after doing tenant/context initialization stuff. Problem with that was : all the files other than .jag files(ex: .css , font files .jpeg etc) are coming to this and when trying to include those it gives a compilation error. You need to include only *.jag files, content of the other files can be piped to the client. Issue with that is, you might need to send proper caching headers etc. from your end. -- *Mahesh Chinthaka Vidanagama* | Software Engineer WSO2, Inc | lean. enterprise. middleware. #20, Palm Grove, Colombo 03, Sri Lanka Mobile: +94 71 63 63 083 | Work: +94 112 145 345 Email: mahe...@wso2.com | Web: www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Fwd: [MB][Fast track Training Project] Requirement Identification : Message Groups for WSO2 Message Broker
Hi, Thanks Ramith. We two will discuss and continue implementation as mentioned. On Thu, Mar 19, 2015 at 3:00 PM, Ramith Jayasinghe ram...@wso2.com wrote: HI Indunil, Chamalee, As per the chat, lets implement option 2. We need to select the subscriber based on the subscription creation/arrival time. regards Ramith On Tue, Mar 17, 2015 at 6:41 AM, Chamalee De Silva chama...@wso2.com wrote: [looping in architecture] ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: ram...@wso2.com P: +94 777542851 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Chamalee De Silva Software Engineer | WSO2 E:chama...@wso2.com nirosh...@wso2.com M :0711540738| http://wso2.com http://wso2.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Meeting Note : Implement a Pluggable Version Strategy feature in APIManager
Hi All,
Please find the implementation details of this.
The user has the ability to define the context by embedding the version
with the {version} param. If that is done, we resolve the {version} param
with the given version of the API. We store both the resolved context and
the context template in the RXT(this is to use when creating new versions
from an existing API)
Ex:- context -- {version}/foo
If the user doesn't give the {version} param, when adding the API, we
append the {version} param to the end of the context. This is to have a
similar behavior as the previous releases where the API URL was
.../{context}/{version}
With this change, in all the places we assume that the version is embedded
in the context and we have done the changes accordingly. At synapse level
all the API's has version-type as context
Please raise any issues you find with this approach.
Thanks,
Janaka
On Mon, Jan 26, 2015 at 1:04 PM, Dinesh J Weerakkody dine...@wso2.com
wrote:
Hi All,
We had a review meeting on 23 Jan 2015 to review the progress of this
feature. Following points were discussed during the meeting.
- RXT file which is created in registry at API creation time will
contain new two field. (Data migration is required when upgrading existing
APIs to new version)
- version-type Ex: none, url, context
- context-template Ex: /{version}/api)
- Resolved context will be stored in the APIM database since those
data is used in key validation service in runtime
- Synapse XML will contain the context template as the context and
will be resolved in deployment time. New version strategy
(ContextVersionStratergy) will be introduced to Sysnapse
- Version strategy used in API will be set to the synapse message
context from synapse side when API is invoked. This will be used in APIM
side when retrieving the details in URL.
Please add if I have missed anything.
Thanks
*Dinesh J. Weerakkody*
Software Engineer
WSO2 Inc.
lean | enterprise | middleware
M : +94 727 361788 | E : dine...@wso2.com | W : www.wso2.com
On Thu, Jan 15, 2015 at 8:08 AM, Dinesh J Weerakkody dine...@wso2.com
wrote:
On Thu, Jan 15, 2015 at 12:17 AM, Nuwan Dias nuw...@wso2.com wrote:
On Tue, Jan 13, 2015 at 11:11 AM, Dinesh J Weerakkody dine...@wso2.com
wrote:
Hi All,
I have tested the above proposed method with a fresh APIM 1.8 pack. We
can successfully create and invoke APIs as follows.
[image: Inline image 1]
Here what we do is simply add the version number to context. Also I
have removed version from the resulting synapse api xml file (smiler to
default version) otherwise we have to send version number after the context
(Ex: http://localhost:8280/1.0.0/docman/*1.0.0*/add).
Now we can invoke this API as follows since context is matching to
request url and this is default version.
http://localhost:8280/1.0.0/docman/add
With the above solution system doesn't allow us to create a new version
of the API. Currently synapse doesn't allow to use deferent contexts with
same API name.
Ex:
Name : DOCMan
Context : */1.0.0/docman*
Version: 1.0.0
Name : DOCMan
Context :* /2.0.0/docman*
Version: 2.0.0
We used a template as a context to overcome this situation.
[image: Inline image 2]
I don't think we should be using {uri.var.version} since it confuses
with uri-templates. What if we just use {version} instead?
Yes, we can use {version} or any string. I just used {uri.var.version}
for the time been.
With this solution context will be same among all versions. We resolve
the context template when API is initializing in synapse runtime. There is
another issue came up with this solution. Synapse doesn't allow to use
version attribute in API xml without a version-type (version strategy)
attribute. URL is the only value that we can use with the version-type
attribute and when we invoke api we must send version after the context if
we use URL as the version strategy. We can introduce a new version strategy
to overcome this situation. For the time been I have disabled the
validation.
After above mentioned changes we can successfully deploy multiple
versions of the same API. But when we try to invoke the APIs we faced
another issue. When the request comes to APIM side there is a problem in
authentication handler.
We use context to check whether access is granted to the given token or
not. In APIM side tables we have context template but in runtime we send
resolved context. So there will be no matching access grants and request
will be rejected.
What if we store the resolved context in the database rather than
storing the template?
We need to keep context template also. We have to display it back in edit
page and also use when we update the API from APIM side.
We have two solutions to overcome this issue.
- Have a separate column in APIM database to store the resolved
context (Use in runtime)
- Add a new
Re: [Architecture] Fwd: [MB][Fast track Training Project] Requirement Identification : Message Groups for WSO2 Message Broker
HI Indunil, Chamalee, As per the chat, lets implement option 2. We need to select the subscriber based on the subscription creation/arrival time. regards Ramith On Tue, Mar 17, 2015 at 6:41 AM, Chamalee De Silva chama...@wso2.com wrote: [looping in architecture] ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: ram...@wso2.com P: +94 777542851 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AppM] [CDM] Mobile Application List Service
Hi Prabath,
Can we finalize the following API's that going to expose from MDM ? App
Manager mobile store need to know the endpoints/data model/security for,
- API to get device list
- API for install
- API for uninstall
- API for update
We need to get a MDM pack with these endpoints to test with App Manager
mobile store end to end scenario. Since App Manager is going to release by
end of March, we won't be able to add changes later.
Regards,
Dinusha.
On Mon, Mar 16, 2015 at 1:00 PM, Dilshan Edirisuriya dils...@wso2.com
wrote:
Hi,
Mobile device will need a reachable IPA URL to get the app downloaded. You
can find a sample plist file [1] here, which need to be generated in order
to get this done.
[1] -
http://stackoverflow.com/questions/25934131/install-in-house-ios-app-wirelessly-with-manifest-plist-does-not-work-anymore-wi
Regards,
Dilshan
On Mon, Mar 16, 2015 at 7:09 AM, Inosh Perera ino...@wso2.com wrote:
Hi Dilshan,
Is it possible to send authorized headers to the AppM through mobile
devices and what about a special case like iOS?
Could you please tell if there is an iOS MDM friendly way to protect the
binary downloading process?
Regards,
Inosh
On Fri, Mar 13, 2015 at 12:56 PM, Sumedha Rubasinghe sume...@wso2.com
wrote:
got it. That also can be included in the url format I suggested above.
On Fri, Mar 13, 2015 at 12:19 PM, Chathura Dilan chathu...@wso2.com
wrote:
Hi Sumedha,
Offset is the starting point for the return data. Say if there are 25
items and someone wants to get last 5 items, he can set the offset to 20
and limit it to 5.
On Fri, Mar 13, 2015 at 12:04 PM, Sumedha Rubasinghe sume...@wso2.com
wrote:
Why not make this something like,
GET apps/mobile/v1 - gives a list of all apps
GET apps/mobile/v1/query - gives a matching app list
GET apps/mobile/v1/query/limit/no of apps - limits the list of
apps shown
- Its more RESTy.
- will also facilitate other type of app downloads
What is the offset about?
On Thu, Mar 5, 2015 at 7:52 AM, Chathura Dilan chathu...@wso2.com
wrote:
Hi All,
To provide app information to CDM, we decided to developed a Jax-RS
web service. This web service will be connected to CDM through mutual
auth.
The information about web service as follows
*Path*
GET mobileapp-services/v1/apps
*Parameters*
*Name*
*Located in*
*Description*
*Required*
*Type*
q
query
Search the app by name
false
string
limit
query
Number of records to be displayed
false
number
offset
query
Offset of the app list
false
number
*Responses*
*Status 200*
Sample Response
{
apps: [
{
id: Szqw45623,
name: WSO2 Con,
type: entrpirse,
platform: android,
version: 1,
location: https://192.168.1.1:9443/apps/app.apk;,
iconImage: https://192.168.1.1:9443/images/app.png;,
packageName: com.wso2.conapp,
identifier: com.wso2.conapp
},
{
id: R456xxEr,
name: Antivirus,
type: public,
platform: android,
version: 1,
iconImage: https://192.168.1.1:9443/images/app1.png;,
packageName: com.wso2.antiv,
identifier: com.wso2.antiv
},
{
id: DD4567we,
name: WSO2 Dinner on Demand,
type: public,
platform: ios,
version: 2,
iconImage: https://192.168.1.1:9443/images/app.png;,
appIdentifier: com.wso2.dod,
identifier: com.wso2.dod
},
{
id: Tyere34343,
name: WSO2 Sports,
type: webapp,
platform: all,
version: 2,
location: https://192.168.1.1:9443/apps/webapp;,
iconImage: https://192.168.1.1:9443/images/app.png;,
identifier: https://192.168.1.1:9443/apps/webapp;
}
],
query: {
status: ok,
found: 4,
length: 10,
offset: 110,
total: 114
}
}
Also Please mention if you need any search queries for this version
of the API
--
Regards,
Chatura Dilan Perera
*(Senior Software Engineer** - WSO2 Inc.**)*
www.dilan.me
--
/sumedha
m: +94 773017743
b : bit.ly/sumedha
--
Regards,
Chatura Dilan Perera
*(Senior Software Engineer** - WSO2 Inc.**)*
www.dilan.me
--
/sumedha
m: +94 773017743
b : bit.ly/sumedha
--
Inosh Perera
Software Engineer, WSO2 Inc.
Tel: 0785293686
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
Dilshan Edirisuriya
Senior Software Engineer - WSO2
Mob: + 94 777878905
http://wso2.com/
https://www.linkedin.com/profile/view?id=50486426
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
Dinusha Dilrukshi
Senior Software Engineer
WSO2 Inc.: http://wso2.com/
Mobile: +94725255071
Blog: http://dinushasblog.blogspot.com/
[Architecture] Analytics Facets APIs in AnalyticsDataService
Hi all,
Analytics facets APIs provide indexing capabilities for hierarchical
categorization of table entries in New analytics data service (Please refer
to [Architecture] BAM 3.0 REST APIs for AnalyticsDataService / Indexing /
Search for more information). Using facet APIs, an user can define
multiple categories as indices for a table and later can be used to search
table entries based on categories. These APIs will be generic, so the user
can assign a weight for each category when indexing, combine a mathematical
function to calculate weights,
*Facet Counts*
As an example in log analysis, consider the following
E.g. log-time : 2015/mar/12/ 20:30:23, 2015/jan/16 13:34:76, 2015/jan/11
01:34:76 ( in 3 different log lines)
In the above example the log time can be defined as a hierarchical facet as
year/month/date. Later if the user wants to get the counts of log entries
by year/month, API would return
2015/jan - Count :2
2015/mar - Count 1
If the user wants to get the total count of log entries by year, API
would return
2015 - Count :3
If the user wants to get the count of log entries by year/month/date, API
returns,
2015/jan/11 - Count :1
2015/jan/16 - Count :1
2015/mar/12 - Count : 1
*Drill-Down capabilities*
Dill down capabilities are provided by Facets APIs. User can drill down
through the facet hierarchy of the index and search table entries. User
also can combine a search query so he can filter out the table entries. As
an example, in above example, User queries for the total count of log lines
in 2015/jan/11 ( he gets 1 as the count) and then he wants to view the
other attributes of the log line ( TID, Component name, log level, ..etc).
*REST APIs for Facets*
Users will be able to use facets API through REST APIs. Users can create
facets indices via the usual Analytics indexing REST APIs and insert
hierarchical category information through Analytics REST APIs, Following
are the updated Analytics REST APIs.
1. Drill-down through a facets hierarchy
/analytics/drilldown or /analytics/drilldown-count
{
tableName :
categories : [{
name : hierarchy name e.g. Publish date
categoryPath : [ ], hierarchy as an array e.g.
[2001, March, 02]
}],
language : lucene or regex
query : lucene query or regular expression
scoreFunction : Javascript function to define scoring function
scoreParams : [] Array of docvalue fields used as parameters for
scoring function
}
2. Querying for Ranges (Additional to facets)
/analytics/searchrange or /analytics/rangecount
{
tableName : sample-table-name,
ranges : [{
label:
from :
to:
minInclusive:
maxInclusive:
}],
language :
query :
}
In addition to the existing index types two more are introduced. They are
FACET and SCOREPARAM. FACET is used to define a hierarchical facet
field and SCOREPARAM is used to define scoring parameters for score
function.
*Adding Facet fields and score fields*
*to a table/tables*
Facet fields and score fields need to be defined using indexing APIs.
/analytics/tables/table-name/indices
{
field : STRING,
facetField : FACET,
scoreField : SCOREPARAM
}
Later user can add facet and score fields using POST to,
/analytics/tables/table-name
[
{
values : {
field : value,
facetField : {
weight :
categoryPath : [ ]
},
scoreField : numeric-value
}
}
]
or /analytics/records
[
{
tableName :
values : {
field : value,
facetField : {
weight :
categoryPath : [ ]
},
scoreField : numeric-value
}
}
]
Feedback and suggestions are appreciated.
--
Gimantha Bandara
Software Engineer
WSO2. Inc : http://wso2.com
Mobile : +94714961919
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
